From hosking at cs.purdue.edu Fri Aug 3 01:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Aug 2007 19:35:08 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <7AAE9AC9-2D63-49F6-8CB5-CD72E5EBF2FB@cs.purdue.edu> I'm pretty sure my latest checkins fix the remaining issues with pthread threading. Please let me know of any further problems. mentor now works reliably for me -- YAY! On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> but after recompiling a second time, it no longer seems to do that. >>> By the way, I am somewhat suspicious that this Juno crash has >>> something to do with threading: if you look closely, that part of >>> Juno has to do with thread switching into and out of the >>> Juno-machine...which is why I was happy to see it disappear (however >>> it did that). >> >> Maybe you had stale code in the build directories? Glad to hear it >> went away after recompiling. >> > > I *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 >>> *** >>> >> >> That is an assert regarding setting the stack size. I wonder if this >> is a Thread.SizedClosure which has a size value that asks for a stack >> size less than PTHREAD_STACK_MIN. I am not sure what the best way to >> handle that is except to disregard the return value from >> pthread_attr_setstacksize. Can you try replacing line 675 in >> ThreadPThread.m3 with: >> >> EVAL Upthread.attr_setstacksize(attr, bytes); >> >> and rebuilding? I am surprised to see that error though, since you >> will note that I get the default stack size from a freshly >> initialized attributes structure on line 673 and use the greater of >> the default size and the requested size. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. > >> Weird, I was running Bresenham just fine yesterday after the fix I >> checked in. Sounds like you may have some stale object files lying >> around. > > I was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). > >> >>> I really don't think it's my old system that's corrupting the new >>> images, >>> but I am *never* 100% certain of that. I found a very weird >>> behavior >>> with the build system, actually. I found that the not-yet-installed >>> compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in >>> /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is >>> that >>> a known/desired behavior? It causes the brand new compiler to >>> use the >>> old cm3.cfg, and it does so quietly without any warnings or messages >>> whatsoever. Changing your PATH makes it stop do that and instead >>> crash, >>> prompting me to put the cm3.cfg I want in the right place... >> >> I was not aware that you are mixing cm3.cfg versions. Why do you >> need both an old and a new one? In any case, this suggests that you >> want to rebuild the new system using the proper cm3.cfg and see if >> your problems go away. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. > > > Mika From hosking at cs.purdue.edu Tue Aug 7 23:48:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 17:48:52 -0400 Subject: [M3devel] LONGINT Message-ID: Shortly I will be checking in compiler and run-time updates that enable the LONGINT type: 32 <= BITSIZE(INTEGER) <= BITSIZE(LONGINT) <= 64 Here are the changes to the language spec, in the form of context diffs to the updated reference manual, which is available at http:// www.cs.purdue.edu/~hosking/m3/reference/index.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diffs Type: application/octet-stream Size: 15769 bytes Desc: not available URL: -------------- next part -------------- I have gone for the minimalist approach to adding LONGINT to the language. In brief, LONGINT is a distinct ordinal type from INTEGER. Conversions can be performed using ORD and VAL. For LONGINT 'n', ORD(n) converts n to an INTEGER. For INTEGER 'n', VAL (n, LONGINT) converts n to a LONGINT. Implicitly, this means all enumerations have an underlying INTEGER representation. LONGINT subranges work as expected. Open arrays are indexed by INTEGER values. Fixed arrays can have an index type whose base type is LONGINT. The rest of the changes to the language spec flow from these fundamentals. From hosking at cs.purdue.edu Wed Aug 8 00:05:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:05:03 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: Just responding to this w.r.to what I have implemented. On Jul 19, 2007, at 5:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? You can use a subrange of LONGINT for array indexes. The effective offset of an array element is still computed as an integer. Arrays are restricted in size, as they are currently. > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. Integers and addresses have the native word size. > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. I have done this. > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > 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 Wed Aug 8 00:07:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:07:08 -0400 Subject: [M3devel] LONGINT In-Reply-To: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> Message-ID: I allow LONGINT indexed arrays, so long as the element offset can be computed as an integer. The size restriction on arrays remains. NUMBER always returns a CARDINAL. Thus, NUMBER(LONGINT) gives a range violation, just as NUMBER(INTEGER) currently does. However, NUMBER([10L .. 20L]) = NUMBER([10..20]) = 11. On Jul 19, 2007, at 6:02 PM, Darko wrote: > I think in 64 bit land you get a variety of combinations and > possibly the most common is a 32 bit address space with 64 bit > integers, since applications seldom need to operate in the larger > address space. But I would think it you wouldn't allocate an object > bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would > be more likely. > > The only situation where I can think of where this is an issue is > using a long integer index in an array of integer proportions, you > could handle this using arithmetic, also illustrates where you'd > need an implicit conversion: > > CONST > start = 2^63-500; > end = 2^63-200; > VAR > a: ARRAY[0..start-end+1] OF CHAR; > BEGIN > FOR i := start TO end DO a[INT(i-start)] := 'x' END; > > > Or you could rule that all arrays are of INTEGER size, but may have > a LONGINT index. Open arrays would always be integers. This would > probably be messy to implement and NUMBER would have a different > base to FIRST and LAST. That doesn't sound very good. > > > > On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > >> >> >> Randy Coleburn wrote: >>> Tony: >>> I'd like to better understand the implications of your change as >>> I do use LONGINT as an index in some applications. >> >> Do you have arrays that need 64-bit subscripts on a 32-bit machine? >> >> Allow me the common assumption that both integers and addresses have >> the native word size on most machines. In this case, most arrays >> that >> need 64-bit subscripts would exceed the virtual address space of the >> machine. Exceptions would require elements of size at most a byte, >> and overall sizes in excess of half the virtual address space. Even >> PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the >> virtual space before 32-bit subscripts ran out. All this seems >> pretty >> unlikely. >> >> I would favor keeping INTEGER as the type of open array subscripts >> and not allowing LONGINT to be a fixed array subscript type. It >> saves a whole lot of language complexity, and doesn't disallow much. >> >> If it really mattered, you could still use unsafe techniques for >> such memory-hogging arrays. This might be a reason to extend unsafe >> arithmetic on ADDRESS to accept LONGINT second operands. This is >> actually consistent with the rest of the operator generalizations. >>> >> >> -- >> ------------------------------------------------------------- >> 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 Wed Aug 8 05:59:12 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 23:59:12 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems Message-ID: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Now I've checked in the LONGINT extensions, I am wondering if we shouldn't observe the following protocol for mapping INTEGER and LONGINT to C types. Currently, we have the following: 32-bit targets 64-bit targets INTEGER 32 bits 64 bits LONGINT 64 bits 64 bits C long int 32 bits 32 bits C long long 64 bits 64 bits I wonder if we shouldn't simply identify INTEGER as 32-bit and LONGINT as 64-bit on all targets. That way, INTEGER=long int and LONGINT=long long. Comments? From hosking at cs.purdue.edu Wed Aug 8 14:39:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:39:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> References: <20070808035016.A852410D440E@birch.elegosoft.com> <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Message-ID: <0B1FC476-C32B-4E57-8DC7-2856E85C1EF8@cs.purdue.edu> Make sure to start with clean build directories and clean before building with the bootstrapped compiler... On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > Amended bootstrap instructions: > > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3cc > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts ./do-cm3-std.sh realclean > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 07/08/08 05:50:13 >> >> Modified files: >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html >> for.html index.html m3.html m3index.html >> numbers.html ordinal.html subtypes.html >> typeops.html word-intf.html >> cm3/m3-db/smalldb/src/: OSSupport.m3 >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 >> SocketPosix.m3 >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 >> cm3/m3-libs/m3core/src/thread/: m3makefile >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 >> Utypes.i3 >> m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/word/: m3makefile >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> cm3/m3-sys/m3front/src/: m3makefile >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 >> Dec.m3 First.m3 Floatt.m3 >> Floor.m3 Inc.m3 Last.m3 >> Max.m3 New.m3 Number.m3 >> Ord.m3 Round.m3 Subarray.m3 >> Trunc.m3 Val.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 >> m3makefile >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 >> WordInsert.m3 WordModule.m3 >> WordNot.m3 WordOr.m3 >> WordRotate.m3 WordShift.m3 >> WordXor.m3 >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 >> CastExpr.m3 CheckExpr.m3 >> CompareExpr.m3 DivExpr.m3 >> EqualExpr.m3 Expr.m3 ExprParse.m3 >> InExpr.m3 IntegerExpr.i3 >> IntegerExpr.m3 ModExpr.m3 >> MultiplyExpr.m3 NegateExpr.m3 >> ReelExpr.i3 ReelExpr.m3 >> SetExpr.m3 SubscriptExpr.m3 >> SubtractExpr.m3 >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 >> Marker.m3 Scanner.m3 TipeDesc.i3 >> TipeDesc.m3 Token.i3 Token.m3 >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 >> ForStmt.m3 TryFinStmt.m3 >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 >> OpenArrayType.m3 SubrangeType.m3 >> Type.i3 Type.m3 >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 >> Module.m3 Variable.m3 >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 >> TWord.i3 TWord.m3 Target.i3 Target.m3 >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 >> M3Lexer.m3 M3Type.i3 M3Type.m3 >> cm3/m3-tools/m3browser/src/: Main.m3 >> Added files: >> cm3/doc/reference/: m3logo.gif >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 >> LongDivide.i3 LongDivide.m3 >> LongExtract.i3 >> LongExtract.m3 LongGE.i3 >> LongGE.m3 LongGT.i3 >> LongGT.m3 LongInsert.i3 >> LongInsert.m3 LongLE.i3 >> LongLE.m3 LongLT.i3 >> LongLT.m3 LongMinus.i3 >> LongMinus.m3 LongMod.i3 >> LongMod.m3 LongModule.i3 >> LongModule.m3 LongNot.i3 >> LongNot.m3 LongOr.i3 >> LongOr.m3 LongPlus.i3 >> LongPlus.m3 LongRotate.i3 >> LongRotate.m3 LongShift.i3 >> LongShift.m3 LongTimes.i3 >> LongTimes.m3 LongXor.i3 >> LongXor.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 >> >> Log message: >> Compiler and runtime extensions to support LONGINT type. >> >> Bootstrapping instructions: build and ship packages in the >> following order >> >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. >> >> Use this new compiler to build and ship the new system: >> >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 >> cd cm3/scripts >> ./do-cm3-std.sh buildship >> >> If this is successful then move the new compiler to BINDIR: >> >> mv $CM3 INSTALL_DIR/bin/cm3 > From hosking at cs.purdue.edu Wed Aug 8 14:31:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:31:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070808035016.A852410D440E@birch.elegosoft.com> References: <20070808035016.A852410D440E@birch.elegosoft.com> Message-ID: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Amended bootstrap instructions: Compiler and runtime extensions to support LONGINT type. Bootstrapping instructions: build and ship packages in the following order m3cc m3middle m3linker m3front m3quake cm3 This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. Use this new compiler to build and ship the new system: export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 cd cm3/scripts ./do-cm3-std.sh buildship If this is successful then move the new compiler to BINDIR: mv $CM3 INSTALL_DIR/bin/cm3 On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 07/08/08 05:50:13 > > Modified files: > cm3/doc/reference/: arithmetic.html arrays.html conventions.html > for.html index.html m3.html m3index.html > numbers.html ordinal.html subtypes.html > typeops.html word-intf.html > cm3/m3-db/smalldb/src/: OSSupport.m3 > cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > SocketPosix.m3 > cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > cm3/m3-libs/m3core/src/thread/: m3makefile > cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > Utypes.i3 > m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/word/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/: m3makefile > cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > Dec.m3 First.m3 Floatt.m3 > Floor.m3 Inc.m3 Last.m3 > Max.m3 New.m3 Number.m3 > Ord.m3 Round.m3 Subarray.m3 > Trunc.m3 Val.m3 > cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > m3makefile > cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > WordInsert.m3 WordModule.m3 > WordNot.m3 WordOr.m3 > WordRotate.m3 WordShift.m3 > WordXor.m3 > cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > CastExpr.m3 CheckExpr.m3 > CompareExpr.m3 DivExpr.m3 > EqualExpr.m3 Expr.m3 ExprParse.m3 > InExpr.m3 IntegerExpr.i3 > IntegerExpr.m3 ModExpr.m3 > MultiplyExpr.m3 NegateExpr.m3 > ReelExpr.i3 ReelExpr.m3 > SetExpr.m3 SubscriptExpr.m3 > SubtractExpr.m3 > cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > Marker.m3 Scanner.m3 TipeDesc.i3 > TipeDesc.m3 Token.i3 Token.m3 > cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > ForStmt.m3 TryFinStmt.m3 > cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > OpenArrayType.m3 SubrangeType.m3 > Type.i3 Type.m3 > cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > Module.m3 Variable.m3 > cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > TWord.i3 TWord.m3 Target.i3 Target.m3 > cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > M3Lexer.m3 M3Type.i3 M3Type.m3 > cm3/m3-tools/m3browser/src/: Main.m3 > Added files: > cm3/doc/reference/: m3logo.gif > cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > LongDivide.i3 LongDivide.m3 > LongExtract.i3 > LongExtract.m3 LongGE.i3 > LongGE.m3 LongGT.i3 > LongGT.m3 LongInsert.i3 > LongInsert.m3 LongLE.i3 > LongLE.m3 LongLT.i3 > LongLT.m3 LongMinus.i3 > LongMinus.m3 LongMod.i3 > LongMod.m3 LongModule.i3 > LongModule.m3 LongNot.i3 > LongNot.m3 LongOr.i3 > LongOr.m3 LongPlus.i3 > LongPlus.m3 LongRotate.i3 > LongRotate.m3 LongShift.i3 > LongShift.m3 LongTimes.i3 > LongTimes.m3 LongXor.i3 > LongXor.m3 > cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > Log message: > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 From darko at darko.org Wed Aug 8 15:30:22 2007 From: darko at darko.org (Darko) Date: Wed, 8 Aug 2007 15:30:22 +0200 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Message-ID: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> This might make sense as a platform option (ie where more than one platform config is available), where 32 bit integer performance is better, or you want to save memory. But INTEGERs are fairly fundamental. For instance, you might actually legitimately want to allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER wouldn't work on it. Will a integer subrange of a 64 bit INTEGER get handled by the back end as efficiently as a 'natively' defined 32 bit integer which is logically defined as a subrange? On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > Now I've checked in the LONGINT extensions, I am wondering if we > shouldn't observe the following protocol for mapping INTEGER and > LONGINT to C types. Currently, we have the following: > > > 32-bit targets 64-bit targets > > INTEGER 32 bits 64 bits > LONGINT 64 bits 64 bits > C long int 32 bits 32 bits > C long long 64 bits 64 bits > > I wonder if we shouldn't simply identify INTEGER as 32-bit and > LONGINT as 64-bit on all targets. That way, INTEGER=long int and > LONGINT=long long. > > Comments? > From rodney.bates at wichita.edu Wed Aug 8 17:20:48 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 10:20:48 -0500 Subject: [M3devel] No m3commit mailing list messages Message-ID: <46B9DF50.20608@wichita.edu> I have made three commits to m3gdb files inside the cm3 repository, on July 13, Aug 5 and Aug. 6. At least the first two seem to have gotten in to the repository, but there are no commit messages to this list. I had a delivery quota problem for a few days around the end of July, but I have checked the list archives via the web, and there are no messages there either. -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Wed Aug 8 21:30:32 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 08 Aug 2007 21:30:32 +0200 Subject: [M3devel] No m3commit mailing list messages In-Reply-To: <46B9DF50.20608@wichita.edu> References: <46B9DF50.20608@wichita.edu> Message-ID: <46BA19D8.1070108@elegosoft.com> You're right. You were not subscribed with rodney at elego.de which is the from address when you commit to our repository. I'm sorry, the person who created the subscriptions might have forgotten this address. Your messages should appear now though. Regards, Ronny Rodney M. Bates schrieb: > I have made three commits to m3gdb files inside the cm3 repository, > on July 13, Aug 5 and Aug. 6. At least the first two seem to have > gotten in to the repository, but there are no commit messages to > this list. I had a delivery quota problem for a few days around > the end of July, but I have checked the list archives via the web, > and there are no messages there either. > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Aug 9 01:10:30 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:10:30 -0500 Subject: [M3devel] Different forms of the language definition Message-ID: <46BA4D66.6040507@wichita.edu> I checked in a .tex, a one-page .html, and a .ps version of the Modula-3 language definition, with the intent to get them consistent with each other and the multi-page html version. Does anyone have any ideas about the best way to derive the different forms from a single source, or how it was originally done? I personally don't find an on-line form very usable, and printing multiple html pages is both tedious to do and rather bad-looking to use. Even a paper print of the one-page html form doesn't look great. My favorite is a .ps or .pdf. But the .ps I had and checked in appears to be been converted from a one-page html form and looks like a print from a web browser. I can easily produce a nice .ps from the .tex with Latex. I am sure some will prefer other forms than I do. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 9 01:20:22 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:20:22 -0500 Subject: [M3devel] Threads summary for m3gdb Message-ID: <46BA4FB6.5090807@wichita.edu> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- 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 rcoleburn at scires.com Thu Aug 9 01:27:55 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 08 Aug 2007 19:27:55 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <46BA192B.1E75.00D7.1@scires.com> Rodney: I believe that on Windows (Win32) the implementation uses native OS threads. At least that is how it worked for cm v4.1. Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Aug 9 10:50:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:50:12 +0200 (CEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: <41532.194.138.127.36.1186649412.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:10, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? It's been some years since I've done it, but you can use LaTeX as source and produce high-quality PS and PDF output (dvips, dvipdf) as well as HTML (there were several tools at the time). Alternatively you could use DocBook/SGML tools (as for example the FreeBSD project does (at least, did some years ago ;-)). Personally I'd think LaTeX is fine and will be easier. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 9 10:53:53 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:53:53 +0200 (CEST) Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <45691.194.138.127.36.1186649633.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:20, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. This is true for the POSIX platforms; on Windows, always native system threads have been used. > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. Pthreads interfaces may be mapped to kernel threads, depending on the operating system and its configuration. > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. I don't think this is correct. GC changes are independent of the threads changes (though both were done by Antony Hosking). He may correct me of course. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? See above, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Aug 9 15:02:49 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 09 Aug 2007 15:02:49 +0200 (MEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: On Wed, 8 Aug 2007, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? > > I personally don't find an on-line form very usable, and printing multiple > html pages is both tedious to do and rather bad-looking to use. Even a > paper print of the one-page html form doesn't look great. My favorite is > a .ps or .pdf. But the .ps I had and checked in appears to be been > converted from a one-page html form and looks like a print from a web > browser. I can easily produce a nice .ps from the .tex with Latex. The PostScript version I downloaded from somewhere years ago looked like generated with TeX (at least not from HTML). I think this is the way to go. From hosking at cs.purdue.edu Fri Aug 10 05:42:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:42:51 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> Message-ID: <7C34CE31-81ED-4488-B0A2-D34D13CC0E0F@cs.purdue.edu> On Aug 8, 2007, at 9:30 AM, Darko wrote: > This might make sense as a platform option (ie where more than one > platform config is available), where 32 bit integer performance is > better, or you want to save memory. But INTEGERs are fairly > fundamental. For instance, you might actually legitimately want to > allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER > wouldn't work on it. On second thoughts.... Given how integer is intimately tied up with Word.T and many assume BITSIZE(INTEGER)=BITSIZE(ADDRESS) I think we probably want INTEGER left as it currently stands. > Will a integer subrange of a 64 bit INTEGER get handled by the back > end as efficiently as a 'natively' defined 32 bit integer which is > logically defined as a subrange? Currently subranges with LONGINT base have values represented as LONGINT. A subrange of LONGINT can be used as an array index for an array, so long as NUMBER(array) is restricted, just as it is currently. > > > > On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > >> Now I've checked in the LONGINT extensions, I am wondering if we >> shouldn't observe the following protocol for mapping INTEGER and >> LONGINT to C types. Currently, we have the following: >> >> >> 32-bit targets 64-bit targets >> >> INTEGER 32 bits 64 bits >> LONGINT 64 bits 64 bits >> C long int 32 bits 32 bits >> C long long 64 bits 64 bits >> >> I wonder if we shouldn't simply identify INTEGER as 32-bit and >> LONGINT as 64-bit on all targets. That way, INTEGER=long int and >> LONGINT=long long. >> >> Comments? >> From hosking at cs.purdue.edu Fri Aug 10 05:58:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:21 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <62EDD983-A3B8-4A11-B1F5-2636FB977A70@cs.purdue.edu> On Aug 8, 2007, at 7:20 PM, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. Yes, though this needs migration to using getcontext/setcontext/ makecontext instead so as to work properly on systems that implement secure setjmp/longjmp. > The new system, called for by -DPTHREAD uses the pthreads library > instead. Yes. gdb handles pthreads on most systems. > There is no use of any kind of kernel threads. pthreads are usually scheduled as a thin veneer over kernel threads. For example, there is a 1-1 map between pthreads and Mach threads on Darwin (similarly for Solaris and Linux). > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. Not true. The old thread system works fine with the new GC. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. Not true. The new GC works fine with the old threads system. > Is this all correct? Hope this helps. > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 05:58:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:51 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA192B.1E75.00D7.1@scires.com> References: <46BA4FB6.5090807@wichita.edu> <46BA192B.1E75.00D7.1@scires.com> Message-ID: <9BAA4292-AD96-43DD-A3C8-0DA4F89D9C4B@cs.purdue.edu> Yes, on Win32, M3 threads are win32 threads. On Aug 8, 2007, at 7:27 PM, Randy Coleburn wrote: > Rodney: > > I believe that on Windows (Win32) the implementation uses native OS > threads. At least that is how it worked for cm v4.1. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > H! ere's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. > > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. > > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. > > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 10:11:24 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Aug 2007 10:11:24 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: Message-ID: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> On Fri, August 10, 2007 01:57, Alex Bochannek wrote: > A couple of quick comments about the CM3 build process on Solaris/SPARC. > > 1) /usr/local/cm3 is hardcoded in a few places in sysinfo.sh. I > installed the minimal binaries in /opt/cm3 and needed to change > sysinfo.sh. I would be surprised if that would be all; supporting other installation locations by the simple build scripts has really not been a target until now. Improvements are always welcome though, so if you have patches that make this abstraction they're sure to get included. > 2) cm3cg is linked against libiconv.so.2. This is not a standard Solaris > library, at least not on Solaris 10. I will install the GNU libiconv and > see if that works. cm3cg is the standard GNU compiler backend, so it may need some (ever increasing) infrastructure (i.e. other GNU libraries). We should either declare this as an explicit dependency (i.e. installation prerequisite) or include it in our installation archives. Probably it hasn't been missing for anybody else using M3 so far, because gcc was always installed before. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Aug 11 15:55:14 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 13:55:14 +0000 Subject: [M3devel] compiling the C code as C++? Message-ID: I was going through diffs I had around. One set is mostly putting #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif around all the C code, and a little something for the K&R code. The point was to compile all the C code as C++. I assume I had it working but I'll have to get back up to speed to verify that. Thoughts? - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:26:56 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:26:56 +0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? Message-ID: I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really? Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some. Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history". All you need is the following: signed and unsigned integer types that are exactly 8 bits in size signed and unsigned integer types that are exactly 16 bits in size signed and unsigned integer types that are exactly 32 bits in size signed and unsigned integer types that are exactly 64 bits in size signed and unsigned integer types that are exactly the size of a pointer 10 integer types total, named something like: INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit: int => INT => INT_PTR unsigned => UINT => UINT_PTR DWORD => DWORD_PTR convert to the upper case types if not there, and append "_PTR" The existing types size_t and ptrdiff_t did change size. If someone really needed 32 bit types there, you'd have to change your code. Windows has more than that for historical and stylistics reasons -- upper case types, lowercase types, types that "favor" being unsigned int or unsigned long. Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary. C 9x adds in "fast" and "small" types types that are the smallest type that is at least a certain size, I think types that are the fastest type that are at least a certain size, I think the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out beyond necessity. Yeah, obviously, they seem like maybe you might want them, but it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient to use on all forseeable processors, since tons of code uses them, and people should not will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are mostly stupid these days and they very often should be widened, but folks can do that "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used. Why has this been so hard in Modula-3? Is it that "Word" is widely used and has been pointer sized? Or that INTEGER has been widely used and sometimes assumed to be pointer sized? Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but weren't done right and there is some legacy we are stuck with?? Do "subrange" types make it all confusing? Or merely the assignment rules among the non subrange integer types? I have not paid particularly close attention; it just has always surprised me that it was difficult to work out what to do. I guess it is all moot now, the issues have been worked out and the feature is there. Good. I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly abstracted C names "short", "int", "long" are a useful abstraction. I think you really want the 10 base types I first listed. btw, even the types that are same size as a pointer are overused in C/C++. You don't need them for as much pointer arithmetic as people use. You can use "char*" for that. They are useful for array indices though, the result of wcslen, sizeof(), etc. File sizes should always be UINT64.. - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 17:15:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 11:15:06 -0400 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> I think you have reasonably illustrated just why C/C++ is such a mess. In M3 we have "BITS n FOR ..." to get appropriately sized things, equivalent to C/C++ char, short, long, long long. The split between INTEGER and LONGINT is unfortunate perhaps, but represents an explicit signal to programmers that INTEGER and LONGINT have different underlying representations, which is in the spirit of Modula-3's existing type system. Perhaps we should be explicit in the C type mappings for M3 by writing: char = BITS 8 FOR ... short = BITS 16 FOR ... int = BITS 32 FOR ... long_long = BITS 64 FOR ... On Aug 11, 2007, at 10:26 AM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! From darko at darko.org Sat Aug 11 17:17:15 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:17:15 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <3AAAC6BE-6742-4B5C-882F-980D1DA39D00@darko.org> The point of M3 is not be different than some other language, the point is for it to be safe, and, as a side effect, easy to use. Making a language safe is hard becuase you have to consider every possible usage and outcome becuase the language guarantees that it will not produce an "unchecked" error for the safe subset of the language, that is, it will do something random no matter how use use the language. So we have to consider all changes very carefully. On 11/08/2007, at 4:26 PM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 17:26:44 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:26:44 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> References: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> Message-ID: <74C18A3E-B31F-4D95-AF21-81A770F86B7E@darko.org> INTEGER in M3 is much more abstract than C, you can use it largely without thinking about what size it is, or at least you should. Portability and simplicity are other benefits you get with M3 compared to C++. On 11/08/2007, at 5:15 PM, Tony Hosking wrote: > I think you have reasonably illustrated just why C/C++ is such a > mess. In M3 we have "BITS n FOR ..." to get appropriately sized > things, equivalent to C/C++ char, short, long, long long. The > split between INTEGER and LONGINT is unfortunate perhaps, but > represents an explicit signal to programmers that INTEGER and > LONGINT have different underlying representations, which is in the > spirit of Modula-3's existing type system. Perhaps we should be > explicit in the C type mappings for M3 by writing: > > char = BITS 8 FOR ... > short = BITS 16 FOR ... > int = BITS 32 FOR ... > long_long = BITS 64 FOR ... > > On Aug 11, 2007, at 10:26 AM, j k wrote: > >> I know, like, the point of Modula-3 is to not be like C or C++ and >> to revisit everything in them, but..really? >> >> Windows programming in C and C++ has had this solved reasonable >> for MANY YEARS. >> Other folks solved it similarly even longer ago, though I would >> claim Windows's >> approach has been successfully applied to more code -- that is, >> all of Windows, and then some. >> >> Windows C/C++ is flawed here, but not in a too terrible way. >> In particular, Windows C/C++ has too many names for the same >> types, with various >> flimsy rationale, mostly "style" and "history". >> >> All you need is the following: >> >> signed and unsigned integer types that are exactly 8 bits in size >> signed and unsigned integer types that are exactly 16 bits in size >> signed and unsigned integer types that are exactly 32 bits in size >> signed and unsigned integer types that are exactly 64 bits in size >> signed and unsigned integer types that are exactly the size of a >> pointer >> >> 10 integer types total, named something like: >> INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, >> size_t or UINT_PTR, ptrdiff_t or INT_PTR >> >> The types "int" and "long" and unsigned thereof NEVER changed size. >> Where people were using them for pointer sized things, you would >> do a simple transform to port to 64 bit: >> int => INT => INT_PTR >> unsigned => UINT => UINT_PTR >> DWORD => DWORD_PTR >> >> convert to the upper case types if not there, and append "_PTR" >> >> The existing types size_t and ptrdiff_t did change size. >> If someone really needed 32 bit types there, you'd have to >> change your code. >> >> Windows has more than that for historical and stylistics reasons >> -- upper case types, >> lowercase types, types that "favor" being unsigned int or >> unsigned long. >> >> Some of it is C's fault -- the "short" and "long" stuff seems all >> unnecessary. >> >> C 9x adds in "fast" and "small" types >> types that are the smallest type that is at least a certain >> size, I think >> types that are the fastest type that are at least a certain >> size, I think >> the idea here being that if 64 bit integers are "faster" than >> 32 bit integers, then "fast32" might be 64 bits >> >> In reality, I think the 10 types are confusing enough, but >> necessary, C9x multiplies out >> beyond necessity. Yeah, obviously, they seem like maybe you >> might want them, but >> it's just too many times imho. Imho 8, 16, and 32 bit integers >> must remain efficient >> to use on all forseeable processors, since tons of code uses >> them, and people should not >> will not be pushed to widen everything across the board. Yeah, >> 64K and 4GB limits are >> mostly stupid these days and they very often should be widened, >> but folks can do that >> "slowly" on their own, managing compatibilit themselves -- like >> where binary file i/o is used. >> >> Why has this been so hard in Modula-3? >> >> Is it that "Word" is widely used and has been pointer sized? >> Or that INTEGER has been widely used and sometimes assumed to be >> pointer sized? >> >> Is it that Sparc64 (?) and 64 bit Alpha have existed for a long >> time but >> weren't done right and there is some legacy we are stuck with?? >> >> Do "subrange" types make it all confusing? >> >> Or merely the assignment rules among the non subrange integer >> types? >> >> I have not paid particularly close attention; it just has always >> surprised me >> that it was difficult to work out what to do. >> >> I guess it is all moot now, the issues have been worked out and >> the feature is there. Good. >> >> I am skeptical that the name "LONGINT" is good. I am skeptical >> that the slightly >> abstracted C names "short", "int", "long" are a useful abstraction. >> I think you really want the 10 base types I first listed. >> >> btw, even the types that are same size as a pointer are overused >> in C/C++. >> You don't need them for as much pointer arithmetic as people use. >> You can use "char*" for that. >> They are useful for array indices though, the result of wcslen, >> sizeof(), etc. >> >> File sizes should always be UINT64.. >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From jayk123 at hotmail.com Sat Aug 11 19:06:57 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:06:57 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: I can build the compiler, but, youch, can't build m3core\long.m3: "..\src\word\Long.m3", line 11: Unknown type of size other than dword in movOp The x86 back end needs work..I'll see if I can't just provide this stuff in C and avoid understanding the backend much.. - Jay> From: hosking at cs.purdue.edu> Date: Wed, 8 Aug 2007 08:39:34 -0400> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > Make sure to start with clean build directories and clean before > building with the bootstrapped compiler...> > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote:> > > Amended bootstrap instructions:> >> > Compiler and runtime extensions to support LONGINT type.> > > > Bootstrapping instructions: build and ship packages in the > > following order> > > > m3cc> > m3middle> > m3linker> > m3front> > m3quake> > cm3> > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> > > > Use this new compiler to build and ship the new system:> > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> > cd cm3/scripts> > ./do-cm3-std.sh realclean> > > ./do-cm3-std.sh buildship> > > > If this is successful then move the new compiler to BINDIR:> > > > mv $CM3 INSTALL_DIR/bin/cm3> >> > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: hosking at birch. 07/08/08 05:50:13> >>> >> Modified files:> >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html> >> for.html index.html m3.html m3index.html> >> numbers.html ordinal.html subtypes.html> >> typeops.html word-intf.html> >> cm3/m3-db/smalldb/src/: OSSupport.m3> >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3> >> SocketPosix.m3> >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3> >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c> >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3> >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3> >> cm3/m3-libs/m3core/src/thread/: m3makefile> >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3> >> Utypes.i3> >> m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/word/: m3makefile> >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> cm3/m3-sys/m3front/src/: m3makefile> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3> >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3> >> Dec.m3 First.m3 Floatt.m3> >> Floor.m3 Inc.m3 Last.m3> >> Max.m3 New.m3 Number.m3> >> Ord.m3 Round.m3 Subarray.m3> >> Trunc.m3 Val.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3> >> m3makefile> >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3> >> WordInsert.m3 WordModule.m3> >> WordNot.m3 WordOr.m3> >> WordRotate.m3 WordShift.m3> >> WordXor.m3> >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3> >> CastExpr.m3 CheckExpr.m3> >> CompareExpr.m3 DivExpr.m3> >> EqualExpr.m3 Expr.m3 ExprParse.m3> >> InExpr.m3 IntegerExpr.i3> >> IntegerExpr.m3 ModExpr.m3> >> MultiplyExpr.m3 NegateExpr.m3> >> ReelExpr.i3 ReelExpr.m3> >> SetExpr.m3 SubscriptExpr.m3> >> SubtractExpr.m3> >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3> >> Marker.m3 Scanner.m3 TipeDesc.i3> >> TipeDesc.m3 Token.i3 Token.m3> >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3> >> ForStmt.m3 TryFinStmt.m3> >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3> >> OpenArrayType.m3 SubrangeType.m3> >> Type.i3 Type.m3> >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3> >> Module.m3 Variable.m3> >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3> >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3> >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3> >> TWord.i3 TWord.m3 Target.i3 Target.m3> >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3> >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3> >> M3Lexer.m3 M3Type.i3 M3Type.m3> >> cm3/m3-tools/m3browser/src/: Main.m3> >> Added files:> >> cm3/doc/reference/: m3logo.gif> >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3> >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3> >> LongDivide.i3 LongDivide.m3> >> LongExtract.i3> >> LongExtract.m3 LongGE.i3> >> LongGE.m3 LongGT.i3> >> LongGT.m3 LongInsert.i3> >> LongInsert.m3 LongLE.i3> >> LongLE.m3 LongLT.i3> >> LongLT.m3 LongMinus.i3> >> LongMinus.m3 LongMod.i3> >> LongMod.m3 LongModule.i3> >> LongModule.m3 LongNot.i3> >> LongNot.m3 LongOr.i3> >> LongOr.m3 LongPlus.i3> >> LongPlus.m3 LongRotate.i3> >> LongRotate.m3 LongShift.i3> >> LongShift.m3 LongTimes.i3> >> LongTimes.m3 LongXor.i3> >> LongXor.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3> >>> >> Log message:> >> Compiler and runtime extensions to support LONGINT type.> >> > >> Bootstrapping instructions: build and ship packages in the > >> following order> >> > >> m3middle> >> m3linker> >> m3front> >> m3quake> >> cm3> >> > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> >> > >> Use this new compiler to build and ship the new system:> >> > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> >> cd cm3/scripts> >> ./do-cm3-std.sh buildship> >> > >> If this is successful then move the new compiler to BINDIR:> >> > >> mv $CM3 INSTALL_DIR/bin/cm3> >> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 19:14:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:14:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <078AEEB2-F545-43ED-B01D-2783D318C4F9@cs.purdue.edu> Did you rebuild the backend? I have built this on Darwin x86 and Linux x86 without problems. On Aug 11, 2007, at 1:06 PM, j k wrote: > I can build the compiler, but, youch, can't build m3core\long.m3: > > "..\src\word\Long.m3", line 11: Unknown type of size other than > dword in movOp > > The x86 back end needs work..I'll see if I can't just provide this > stuff in C and avoid understanding the backend much.. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Wed, 8 Aug 2007 08:39:34 -0400 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Make sure to start with clean build directories and clean before > > building with the bootstrapped compiler... > > > > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > > > > > Amended bootstrap instructions: > > > > > > Compiler and runtime extensions to support LONGINT type. > > > > > > Bootstrapping instructions: build and ship packages in the > > > following order > > > > > > m3cc > > > m3middle > > > m3linker > > > m3front > > > m3quake > > > cm3 > > > > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > > > > > Use this new compiler to build and ship the new system: > > > > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > > cd cm3/scripts > > > > ./do-cm3-std.sh realclean > > > > > ./do-cm3-std.sh buildship > > > > > > If this is successful then move the new compiler to BINDIR: > > > > > > mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: hosking at birch. 07/08/08 05:50:13 > > >> > > >> Modified files: > > >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html > > >> for.html index.html m3.html m3index.html > > >> numbers.html ordinal.html subtypes.html > > >> typeops.html word-intf.html > > >> cm3/m3-db/smalldb/src/: OSSupport.m3 > > >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > > >> SocketPosix.m3 > > >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > > >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > > >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > > >> cm3/m3-libs/m3core/src/thread/: m3makefile > > >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > > >> Utypes.i3 > > >> m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/word/: m3makefile > > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> cm3/m3-sys/m3front/src/: m3makefile > > >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > > >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > > >> Dec.m3 First.m3 Floatt.m3 > > >> Floor.m3 Inc.m3 Last.m3 > > >> Max.m3 New.m3 Number.m3 > > >> Ord.m3 Round.m3 Subarray.m3 > > >> Trunc.m3 Val.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > > >> m3makefile > > >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > > >> WordInsert.m3 WordModule.m3 > > >> WordNot.m3 WordOr.m3 > > >> WordRotate.m3 WordShift.m3 > > >> WordXor.m3 > > >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > > >> CastExpr.m3 CheckExpr.m3 > > >> CompareExpr.m3 DivExpr.m3 > > >> EqualExpr.m3 Expr.m3 ExprParse.m3 > > >> InExpr.m3 IntegerExpr.i3 > > >> IntegerExpr.m3 ModExpr.m3 > > >> MultiplyExpr.m3 NegateExpr.m3 > > >> ReelExpr.i3 ReelExpr.m3 > > >> SetExpr.m3 SubscriptExpr.m3 > > >> SubtractExpr.m3 > > >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > > >> Marker.m3 Scanner.m3 TipeDesc.i3 > > >> TipeDesc.m3 Token.i3 Token.m3 > > >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > > >> ForStmt.m3 TryFinStmt.m3 > > >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > > >> OpenArrayType.m3 SubrangeType.m3 > > >> Type.i3 Type.m3 > > >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > > >> Module.m3 Variable.m3 > > >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > > >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > > >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > > >> TWord.i3 TWord.m3 Target.i3 Target.m3 > > >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > > >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > > >> M3Lexer.m3 M3Type.i3 M3Type.m3 > > >> cm3/m3-tools/m3browser/src/: Main.m3 > > >> Added files: > > >> cm3/doc/reference/: m3logo.gif > > >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > > >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > > >> LongDivide.i3 LongDivide.m3 > > >> LongExtract.i3 > > >> LongExtract.m3 LongGE.i3 > > >> LongGE.m3 LongGT.i3 > > >> LongGT.m3 LongInsert.i3 > > >> LongInsert.m3 LongLE.i3 > > >> LongLE.m3 LongLT.i3 > > >> LongLT.m3 LongMinus.i3 > > >> LongMinus.m3 LongMod.i3 > > >> LongMod.m3 LongModule.i3 > > >> LongModule.m3 LongNot.i3 > > >> LongNot.m3 LongOr.i3 > > >> LongOr.m3 LongPlus.i3 > > >> LongPlus.m3 LongRotate.i3 > > >> LongRotate.m3 LongShift.i3 > > >> LongShift.m3 LongTimes.i3 > > >> LongTimes.m3 LongXor.i3 > > >> LongXor.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > >> > > >> Log message: > > >> Compiler and runtime extensions to support LONGINT type. > > >> > > >> Bootstrapping instructions: build and ship packages in the > > >> following order > > >> > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > >> > > >> Use this new compiler to build and ship the new system: > > >> > > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > >> cd cm3/scripts > > >> ./do-cm3-std.sh buildship > > >> > > >> If this is successful then move the new compiler to BINDIR: > > >> > > >> mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > > > Recharge--play some free games. Win cool prizes too! Play It! From hosking at cs.purdue.edu Sat Aug 11 19:19:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:19:56 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details References: <200708111715.l7BHFAJn017822@hermes50.mail.cornell.edu> Message-ID: Jay, your e-mails are bouncing. Begin forwarded message: > From: Mail Delivery Subsystem > Date: August 11, 2007 1:15:10 PM EDT > To: hosking at cs.purdue.edu > Subject: Returned mail: see transcript for details > > The original message was received at Sat, 11 Aug 2007 13:15:10 > -0400 (EDT) > from daemon at localhost > > ----- The following addresses had permanent fatal errors ----- > jaykrell at verizon.net > > ----- Transcript of session follows ----- > ... while talking to relay.verizon.net.: >>>> DATA > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > 550 5.1.1 jaykrell at verizon.net... User unknown > <<< 554 5.5.0 No recipients have been specified. > Reporting-MTA: dns; hermes50.mail.cornell.edu > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > Final-Recipient: RFC822; jaykrell at verizon.net > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; relay.verizon.net > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > From: Tony Hosking > Date: August 11, 2007 1:14:21 PM EDT > To: > Cc: Modula-3 developers , > > Subject: Re: [M3commit] CVS Update: cm3 > > > Did you rebuild the backend? > > I have built this on Darwin x86 and Linux x86 without problems. > > On Aug 11, 2007, at 1:06 PM, j k wrote: > >> I can build the compiler, but, youch, can't build m3core\long.m3: >> >> "..\src\word\Long.m3", line 11: Unknown type of size other than >> dword in movOp >> >> The x86 back end needs work..I'll see if I can't just provide this >> stuff in C and avoid understanding the backend much.. >> >> - Jay >> From jayk123 at hotmail.com Sat Aug 11 19:55:06 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:55:06 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:53:00 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:53:00 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Ok, other than calling it "the x86 backend", I think I'm right. I wasn't sure if it was for all x86 platforms or just Windows.How about the "non gcc" backend? I think only Windows uses it and no other platform.I can get much further still having fixed BuildStandalone functionality in m3-sys\cminstall\src\config\NT386. I broke it a few months ago. I got as far as m3ui and something with RTHeapDep, I think the problem there is the interface got deleted between the last binary distribution and now. I'll dig a bit more.After fixing BuildStandalone, tried again with the inline Long.m3 and got the same errors so I put back my C implementation -- I am NOT sure it is right, either in calling convention or in implementing the shift/rotate/extract/insert stuff correctly.Now cm3 -ship works on m3core.dll as well but that's a different point. - JayFrom: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Sat, 11 Aug 2007 17:55:06 +0000Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> New home for Mom, no cleanup required. All starts here. _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:54:55 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:54:55 +0000 Subject: [M3devel] missing commits Message-ID: fyi, I'm not seeing my commits, probably my fault with my screwy-for-months-now mail configuration. I do intend to fix it soon... - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 21:03:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 15:03:32 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details In-Reply-To: References: Message-ID: Ah, yes the Windows (non-gcc) x86 backed will certainly need fixing to handle 64-bit integers. I had forgotten that Windows does not use the gcc-based backend. The principal differences can probably be figured out by looking at how Long.m3 gets compiled. Take a look at the changes to M3CG_Ops.i3 to get a sense for what changes were made to the interface between the middle and back ends. On Aug 11, 2007, at 2:53 PM, j k wrote: > Ok, other than calling it "the x86 backend", I think I'm right. I > wasn't sure if it was for all x86 platforms or just Windows. > > How about the "non gcc" backend? I think only Windows uses it and > no other platform. > > I can get much further still having fixed BuildStandalone > functionality in m3-sys\cminstall\src\config\NT386. I broke it a > few months ago. I got as far as m3ui and something with RTHeapDep, > I think the problem there is the interface got deleted between the > last binary distribution and now. I'll dig a bit more. > > After fixing BuildStandalone, tried again with the inline Long.m3 > and got the same errors so I put back my C implementation -- I am > NOT sure it is right, either in calling convention or in > implementing the shift/rotate/extract/insert stuff correctly. > > Now cm3 -ship works on m3core.dll as well but that's a different > point. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sat, 11 Aug 2007 17:55:06 +0000 > Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details > > Yeah sorry I have to fix that forwarding, been broken for months > but almost have it fixed. > jayk123 at hotmail.com works. > > Hm. Geez I don't know. I guess I should stop submitting for now. > Let me figure more stuff out. > > I built cm3.exe and am running it. I had more errors before fixing > the Windows clearenv.cmd, I submitted a fix for it -- it was > clearing %cm3%. > > I have to track down where the gcc vs. no gcc decision is made. > Maybe it is only x86 Windows that uses this code, not all x86 > platforms? > > I can get further with my changes but then I crash and I probably > won't make much more progress today. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 13:19:56 -0400 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Fwd: Returned mail: see transcript for details > > > > Jay, your e-mails are bouncing. > > > > Begin forwarded message: > > > > > From: Mail Delivery Subsystem > > > Date: August 11, 2007 1:15:10 PM EDT > > > To: hosking at cs.purdue.edu > > > Subject: Returned mail: see transcript for details > > > > > > The original message was received at Sat, 11 Aug 2007 13:15:10 > > > -0400 (EDT) > > > from daemon at localhost > > > > > > ----- The following addresses had permanent fatal errors ----- > > > jaykrell at verizon.net > > > > > > ----- Transcript of session follows ----- > > > ... while talking to relay.verizon.net.: > > >>>> DATA > > > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > > > 550 5.1.1 jaykrell at verizon.net... User unknown > > > <<< 554 5.5.0 No recipients have been specified. > > > Reporting-MTA: dns; hermes50.mail.cornell.edu > > > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > Final-Recipient: RFC822; jaykrell at verizon.net > > > Action: failed > > > Status: 5.1.1 > > > Remote-MTA: DNS; relay.verizon.net > > > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > From: Tony Hosking > > > Date: August 11, 2007 1:14:21 PM EDT > > > To: > > > Cc: Modula-3 developers , > > > > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Did you rebuild the backend? > > > > > > I have built this on Darwin x86 and Linux x86 without problems. > > > > > > On Aug 11, 2007, at 1:06 PM, j k wrote: > > > > > >> I can build the compiler, but, youch, can't build m3core\long.m3: > > >> > > >> "..\src\word\Long.m3", line 11: Unknown type of size other than > > >> dword in movOp > > >> > > >> The x86 back end needs work..I'll see if I can't just provide > this > > >> stuff in C and avoid understanding the backend much.. > > >> > > >> - Jay > > >> > > > > > New home for Mom, no cleanup required. All starts here. > Messenger Caf? ? open for fun 24/7. Hot games, cool activities > served daily. Visit now. From darko at darko.org Sat Aug 11 22:15:22 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 22:15:22 +0200 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> The last commit I got was beginning of April. I think there might be a wider problem. On 11/08/2007, at 8:54 PM, j k wrote: > fyi, I'm not seeing my commits, probably my fault with my screwy- > for-months-now mail configuration. I do intend to fix it soon... > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 01:01:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 19:01:40 -0400 Subject: [M3devel] missing commits In-Reply-To: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> References: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> Message-ID: <7B496A29-42B3-499E-9CF9-5AF651C72075@cs.purdue.edu> I know there was a problem with the mailing list and I ended up re- subscribing using my CVS username from the elegosoft web-site. It seems that commits via CVS accounts pipe to the mailing list, but you need to be subscribed with that id. On Aug 11, 2007, at 4:15 PM, Darko wrote: > The last commit I got was beginning of April. I think there might > be a wider problem. > > > On 11/08/2007, at 8:54 PM, j k wrote: > >> fyi, I'm not seeing my commits, probably my fault with my screwy- >> for-months-now mail configuration. I do intend to fix it soon... >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From rodney.bates at wichita.edu Sun Aug 12 02:44:18 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 11 Aug 2007 19:44:18 -0500 Subject: [M3devel] Latex M3 language definition Message-ID: <46BE57E2.90307@wichita.edu> I propose to fix up m3-defn-complete.tex as much as possible before adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can have an up to date-PM3-definition. The .tex I found does not have any face tags for the code samples in the running text (as does the .html), nor does it have anything denoting the hyperlinks in it. I guess they will have to be inserted manually. This would quite a bit of stuff to try to merge with the CM3 changes, if they were to get done first. Other than that, the .tex looks like the actual content is very close to identical to the .html one-page form. I did a careful parallel reading, (as close as mere mortals could have much hope of doing). So the .tex is not exactly the predecessor that the .html was derived from. I have done some net searching trying to find another .tex, but to no avail, so far. It does look like latex2html will do what is needed, particularly allowing tex tags that will turn into hyperlinks in html and get ignored by latex for a printed version. It also appears to have something for optionally generating multi-page html as well. I think there is a successor to it, but haven't checked that out yet. -- ------------------------------------------------------------- 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 Sun Aug 12 04:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 22:05:28 -0400 Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: I'm halfwa done on some of that, so hang on a mo'. On Aug 11, 2007, at 8:44 PM, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. > > Other than that, the .tex looks like the actual content is very close > to identical to the .html one-page form. I did a careful parallel > reading, (as close as mere mortals could have much hope of doing). > So the .tex is not exactly the predecessor that the .html was derived > from. I have done some net searching trying to find another .tex, > but to no avail, so far. > > It does look like latex2html will do what is needed, particularly > allowing tex tags that will turn into hyperlinks in html and get > ignored by latex for a printed version. It also appears to have > something for optionally generating multi-page html as well. I think > there is a successor to it, but haven't checked that out yet. > > -- > ------------------------------------------------------------- > 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 lemming at henning-thielemann.de Sun Aug 12 06:52:29 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 12 Aug 2007 06:52:29 +0200 (MEST) Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: On Sat, 11 Aug 2007, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. I also remember that the Module-3 definition states that only one exception per EXCEPTION keyword can be defined, which seems to be relaxed in cm3 and pm3. From derick_eddington at yahoo.com Sun Aug 12 06:49:23 2007 From: derick_eddington at yahoo.com (Derick Eddington) Date: Sat, 11 Aug 2007 21:49:23 -0700 (PDT) Subject: [M3devel] unsubcribe Message-ID: <982895.80961.qm@web58713.mail.re1.yahoo.com> ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From jayk123 at hotmail.com Sun Aug 12 07:24:06 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 05:24:06 +0000 Subject: [M3devel] missing commits Message-ID: I am getting Tony's .tex commits, but didn't see mine.I say this half to cover my butt -- I made some commits.If I'm not seeing them, others maybe aren't either.I added a C version of Long.m3 for Win32.Not sure it is right, in a few ways. How it uses the stack. If it shifts and all by the right amounts? (n or 64 - n?) It definitely lets the build progress further. Surely it isn't ideal -- the C code actually generates calls out to the C runtime even, under the covers, so what was meant to be inlined is a two deep call tree! (The compiler generates the calls.)I fixed cminstall/src/config/NT386 so BuildStandalone works.I fixed scripts/win/clearenv.cmd so the user can set CM3 as per Tony's bootstrap instructions.Maybe others, don't recall.Nothing large.I figure I'll remove a bunch of extra semicolons in some C code.Any thoughts on the #ifdef __cplusplus extern "C" in C code? - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 19:01:40 -0400> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > I know there was a problem with the mailing list and I ended up re- > subscribing using my CVS username from the elegosoft web-site. It > seems that commits via CVS accounts pipe to the mailing list, but you > need to be subscribed with that id.> > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > > The last commit I got was beginning of April. I think there might > > be a wider problem.> >> >> > On 11/08/2007, at 8:54 PM, j k wrote:> >> >> fyi, I'm not seeing my commits, probably my fault with my screwy- > >> for-months-now mail configuration. I do intend to fix it soon...> >>> >> - Jay> >>> >> Recharge--play some free games. Win cool prizes too! Play It!> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 10:16:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 04:16:22 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <389194AD-D205-47E0-808A-E6BBC15A2CA3@cs.purdue.edu> Why do you need a C version of Long.m3 for Win32? These operations are built into the front-end, making use of backend functionality. On Aug 12, 2007, at 1:24 AM, j k wrote: > I am getting Tony's .tex commits, but didn't see mine. > I say this half to cover my butt -- I made some commits. > If I'm not seeing them, others maybe aren't either. > > I added a C version of Long.m3 for Win32. > Not sure it is right, in a few ways. > How it uses the stack. > If it shifts and all by the right amounts? (n or 64 - n?) > It definitely lets the build progress further. > Surely it isn't ideal -- the C code actually generates > calls out to the C runtime even, under the covers, so what > was meant to be inlined is a two deep call tree! > (The compiler generates the calls.) > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > I fixed scripts/win/clearenv.cmd so the user > can set CM3 as per Tony's bootstrap instructions. > > Maybe others, don't recall. > Nothing large. > > I figure I'll remove a bunch of extra semicolons in some C code. > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > To: darko at darko.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > I know there was a problem with the mailing list and I ended up re- > > subscribing using my CVS username from the elegosoft web-site. It > > seems that commits via CVS accounts pipe to the mailing list, but > you > > need to be subscribed with that id. > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > The last commit I got was beginning of April. I think there might > > > be a wider problem. > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > >> fyi, I'm not seeing my commits, probably my fault with my screwy- > > >> for-months-now mail configuration. I do intend to fix it soon... > > >> > > >> - Jay > > >> > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Sun Aug 12 14:39:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 12 Aug 2007 14:39:34 +0200 Subject: [M3devel] Error building cvshead m3gdb od x86_64 Linux Message-ID: <1186922374.9120.24.camel@faramir.m3w.org> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/i386-linux-nat.c In file included from ../../gdb/gdb/i386-linux-nat.c:65: ../../gdb/gdb/gregset.h:63: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?gdb_fpxregset_t? ../../gdb/gdb/gregset.h:65: error: expected ?)? before ?*? token ../../gdb/gdb/gregset.h:66: error: expected ?)? before ?*? token -- Dragi?a Duri? From jayk123 at hotmail.com Sun Aug 12 21:20:07 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:20:07 +0000 Subject: [M3devel] missing commits Message-ID: Because it doesn't work currently. This was easier but I agree not ideal. - Jay> From: hosking at cs.purdue.edu> Date: Sun, 12 Aug 2007 04:16:22 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > Why do you need a C version of Long.m3 for Win32? These operations > are built into the front-end, making use of backend functionality.> > On Aug 12, 2007, at 1:24 AM, j k wrote:> > > I am getting Tony's .tex commits, but didn't see mine.> > I say this half to cover my butt -- I made some commits.> > If I'm not seeing them, others maybe aren't either.> >> > I added a C version of Long.m3 for Win32.> > Not sure it is right, in a few ways.> > How it uses the stack.> > If it shifts and all by the right amounts? (n or 64 - n?)> > It definitely lets the build progress further.> > Surely it isn't ideal -- the C code actually generates> > calls out to the C runtime even, under the covers, so what> > was meant to be inlined is a two deep call tree!> > (The compiler generates the calls.)> >> > I fixed cminstall/src/config/NT386 so BuildStandalone works.> >> > I fixed scripts/win/clearenv.cmd so the user> > can set CM3 as per Tony's bootstrap instructions.> >> > Maybe others, don't recall.> > Nothing large.> >> > I figure I'll remove a bunch of extra semicolons in some C code.> >> > Any thoughts on the #ifdef __cplusplus extern "C" in C code?> >> > - Jay> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 11 Aug 2007 19:01:40 -0400> > > To: darko at darko.org> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] missing commits> > >> > > I know there was a problem with the mailing list and I ended up re-> > > subscribing using my CVS username from the elegosoft web-site. It> > > seems that commits via CVS accounts pipe to the mailing list, but > > you> > > need to be subscribed with that id.> > >> > > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > >> > > > The last commit I got was beginning of April. I think there might> > > > be a wider problem.> > > >> > > >> > > > On 11/08/2007, at 8:54 PM, j k wrote:> > > >> > > >> fyi, I'm not seeing my commits, probably my fault with my screwy-> > > >> for-months-now mail configuration. I do intend to fix it soon...> > > >>> > > >> - Jay> > > >>> > > >> Recharge--play some free games. Win cool prizes too! Play It!> > > >> > >> >> > See what you?re getting into?before you go there See it!> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:27:05 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:27:05 +0000 Subject: [M3devel] new Win32 build from current source Message-ID: Can folks try this? Make it available on the web page?There hasn't been a win32 release for longer than other platforms.I can build "core" and "std" if folks want.These files are directly output from scripts\win\make-dist.cmd. It has the support for "core" and "std", commented out. If folks prefer, tar.gz, .zip, and self extracting .zip are possible; .bz2 is smallest. Perhaps a version number should be in the .tar path structure? The install instructions are like (no cminstall, replaced by using vcvars32.bat which lets one CM3 install move among different tools, debatable which is better) cd /d c:\ optionally rmdir /q/s cm3 tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 run the usual vcvars32.bat or whatever (or use the start menu link that Visual C++ setup creates) set PATH=c:\cm3\bin;%PATH% set LIB=c:\cm3\lib;%lib% optionally, a good test: cd \scripts\win .\do-pkg-std realclean .\do-pkg-std buildship I have not tested the longint stuff and it likely doesn't work yet. The files are in ~jkrell on m3.elegosoft.com: C:\>ssh jkrell at m3.elegosoft.com find . ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 Remember you will need http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 or I could build it with an older toolset if folks want. Thanks, - Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 21:32:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:32:02 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <14E40138-3008-42B2-AD21-C6AA96DFFA12@cs.purdue.edu> Not only not ideal, but deferring the pain. We need to be able to compile 64-bit operations on 32-bit machines and that means updating the backend. Long.m3 is a good test-case for all the ops that you need for LONGINT support. On Aug 12, 2007, at 3:20 PM, j k wrote: > Because it doesn't work currently. This was easier but I agree not > ideal. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sun, 12 Aug 2007 04:16:22 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > Why do you need a C version of Long.m3 for Win32? These operations > > are built into the front-end, making use of backend functionality. > > > > On Aug 12, 2007, at 1:24 AM, j k wrote: > > > > > I am getting Tony's .tex commits, but didn't see mine. > > > I say this half to cover my butt -- I made some commits. > > > If I'm not seeing them, others maybe aren't either. > > > > > > I added a C version of Long.m3 for Win32. > > > Not sure it is right, in a few ways. > > > How it uses the stack. > > > If it shifts and all by the right amounts? (n or 64 - n?) > > > It definitely lets the build progress further. > > > Surely it isn't ideal -- the C code actually generates > > > calls out to the C runtime even, under the covers, so what > > > was meant to be inlined is a two deep call tree! > > > (The compiler generates the calls.) > > > > > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > > > > > I fixed scripts/win/clearenv.cmd so the user > > > can set CM3 as per Tony's bootstrap instructions. > > > > > > Maybe others, don't recall. > > > Nothing large. > > > > > > I figure I'll remove a bunch of extra semicolons in some C code. > > > > > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > > > To: darko at darko.org > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] missing commits > > > > > > > > I know there was a problem with the mailing list and I ended > up re- > > > > subscribing using my CVS username from the elegosoft web- > site. It > > > > seems that commits via CVS accounts pipe to the mailing list, > but > > > you > > > > need to be subscribed with that id. > > > > > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > > > > > The last commit I got was beginning of April. I think there > might > > > > > be a wider problem. > > > > > > > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > > > > > >> fyi, I'm not seeing my commits, probably my fault with my > screwy- > > > > >> for-months-now mail configuration. I do intend to fix it > soon... > > > > >> > > > > >> - Jay > > > > >> > > > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > > > > > > > > > See what you?re getting into?before you go there See it! > > > > > New home for Mom, no cleanup required. All starts here. From hosking at cs.purdue.edu Sun Aug 12 21:34:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:34:30 -0400 Subject: [M3devel] new Win32 build from current source In-Reply-To: References: Message-ID: <83F32D11-E8ED-4CD8-B400-F3DDE7795D56@cs.purdue.edu> LONGINT will need work on the native x86 backend. Should not be too hard, given how little needed to change for the gcc-based backend to handle LONGINT. [PS I have a couple of fixes to LONGINT that I am working on in the front-end compiler. Issues with LONGINT subranges and their representation. I am hoping this fixes the bug I discovered in LONGINT on PPC_DARWIN w.r.to off_t in file stat structs.] On Aug 12, 2007, at 3:27 PM, j k wrote: > Can folks try this? Make it available on the web page? > There hasn't been a win32 release for longer than other platforms. > I can build "core" and "std" if folks want. > These files are directly output from scripts\win\make-dist.cmd. > It has the support for "core" and "std", commented out. > If folks prefer, tar.gz, .zip, and self extracting .zip are > possible; .bz2 is smallest. > Perhaps a version number should be in the .tar path structure? > > The install instructions are like (no cminstall, replaced by using > vcvars32.bat which lets one CM3 install move among different tools, > debatable which is better) > > cd /d c:\ > optionally rmdir /q/s cm3 > tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > run the usual vcvars32.bat or whatever (or use the start menu link > that Visual C++ setup creates) > set PATH=c:\cm3\bin;%PATH% > set LIB=c:\cm3\lib;%lib% > > optionally, a good test: > cd \scripts\win > .\do-pkg-std realclean > .\do-pkg-std buildship > > I have not tested the longint stuff and it likely doesn't work yet. > > The files are in ~jkrell on m3.elegosoft.com: > C:\>ssh jkrell at m3.elegosoft.com find . > > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Remember you will need > http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE- > A3F9-4C13-9C99-220B62A191EE > or http://www.microsoft.com/downloads/details.aspx? > FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 > > or I could build it with an older toolset if folks want. > > Thanks, > - Jay > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Sun Aug 12 21:39:31 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:39:31 +0000 Subject: [M3devel] Some random notes on building/running Modula-3 on Windows (XP). Message-ID: Some of this is redundant -- i.e. has long been working. Some of it is specific to my configuration and habits. You are expected to recognize that. :) I am running Windows XP and currently using Visual C++ 8.0, though many versions of NT and VC should work. Some work has been put into ensuring multiple versions of VC work. Checkout the latest source. Really the latest. (at least of August 12 11am Pacific time). Download and extract the "latest" binary distribution, it is old but ok: cm3-min-WIN32-NT386-5.2.6.tar.bz2 Or maybe it was .gz, I always change them to save space. For me it is at C:\net\modula3\cm3-min-WIN32-NT386-5.2.6.tar.bz2 I install to the default c:\cm3. Prior to running cminstall, mkdir c:\cm3\t. Whenever cminstall asks for a path to a directory, just say c:\cm3\t. (It insists on an existing path, but with my configuration file, which is generic and checked in, none of them are used.) None of these paths matters if you do things this way. After running cminstall, you may rmdir the empty c:\cm3\t. Replace c:\cm3\bin\cm3.cfg with the latest source's cm3\m3-sys\cminstall\src\config\NT386. No edits are necessary. Or, if doing this repeatedly, I have it like so: cm3-min-WIN32-NT386-5.2.6.tar.bz2 is extracted to \net\modula3\cm3-min-WIN32-NT386-5.2.6\t and modified: delete bin\cm3.cfg delete bin\cm3.cfg--default and then to restore just: xcopy /fiveryh \net\modula3\cm3-min-WIN32-NT386-5.2.6\t \cm3 You need /h for hidden because tar will hide files like .M3EXPORTS that start with a dot. t for temp Setup your Visual C++ environment (%PATH%, %LIB%, %INCLUD%) by running the usual vcvars32.bat. For me this is running \env\cm3.vc80.bat (also have \env\cm3.vc20.bat, 40, 41, 42, 50, 60, 70, 71) set LIB=c:\cm3\lib;%LIB% set PATH=c:\cm3\bin;%PATH% Given the source tree at \dev2\cm3.2 I use \dev2 since Unix "takes" \dev. cm3.2 is because cm3 is an older tree I need to get the diffs out of and delete. These instructions are based on Tony's and very similar. Mainly that Windows does not use gcc. cd \dev2\cm3.2\scripts\win @rem make sure %CM3% is clear, in case of running through this stuff multiple times. set CM3= .\do-pkg realclean import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 .\do-pkg buildship import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 set CM3=C:\dev2\cm3.2\m3-sys\cm3\NT386\cm3.exe .\do-cm3-std realclean .\do-cm3-std buildship .\install-cm3-compiler upgrade Alternatively: extract/install/configure latest distribution as above checkout latest source cd scripts\win .\make-dist This gives you: cm3-min-WIN32-NT386-d5.3.2.tar.bz2 cm3-min-WIN32-NT386-d5.3.2-symbols.tar.bz2 buried in temp. I have not tested the new LONGINT functionality and there's a good chance it doesn't work yet. Various GUI apps start up ok. formsedit starts up and show gui. juno starts and shows gui, but crashes easily: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x5aaf8f8 0xf4fc2c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x5aafd54 0xf4db55 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... vorun brings up gui visobliq brings up gui not sure how to exit, had to kill it shownew brings up gui showheap brings up gui showthread brings up gui - Jay _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Mon Aug 13 21:44:47 2007 From: stsp at elego.de (Stefan Sperling) Date: Mon, 13 Aug 2007 21:44:47 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813143915.71BE510D4363@birch.elegosoft.com> References: <20070813143915.71BE510D4363@birch.elegosoft.com> Message-ID: <20070813194447.GE1351@ted.stsp.lan> On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 07/08/13 16:39:15 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c > > Log message: > No change to the contents of these files. This is an attempt to get > the time stampof ada-lex.c to be later than that of ada-lex.l. This > will mean m3gdb will build without requiring flex to be installed. What about hacking a 'touch ada-lex.c' into the Makefile somewhere instead? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rodney.bates at wichita.edu Mon Aug 13 23:41:32 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 16:41:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813194447.GE1351@ted.stsp.lan> References: <20070813143915.71BE510D4363@birch.elegosoft.com> <20070813194447.GE1351@ted.stsp.lan> Message-ID: <46C0D00C.5030903@wichita.edu> This works when I do a complete fresh cvs checkout on a different machine and build, with flex disabled. The checked-out files on the second machine show the times I edited my originals on the first machine, before committing. But when, on yet a 3rd machine, I do a cvs update, both files show identical times, the time that the update happened. So something more is needed. Is there a way to get cvs to give updated files the time they have in the repository, instead of when updated? If anybody ever actually did change ada-lex.l, a touch ada-lex.c in the makefile would be wrong. After what I did, people who do an update now may go from building fine (since they got the files initially from a checkout, which gives the right time ordering), to failing. Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > >>CVSROOT: /usr/cvs >>Changes by: rodney at birch. 07/08/13 16:39:15 >> >>Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c >> >>Log message: >> No change to the contents of these files. This is an attempt to get >> the time stampof ada-lex.c to be later than that of ada-lex.l. This >> will mean m3gdb will build without requiring flex to be installed. > > > What about hacking a 'touch ada-lex.c' into the Makefile somewhere > instead? > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:11:44 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:11:44 -0500 Subject: [M3devel] A note on bootstrapping cm3 Message-ID: <46C0D720.90202@wichita.edu> If you have not rebootstrapped cm3 in a while, you may have, in your cm3.cfg, something similar to: GCWRAPFLAGS = "-Wl,--wrap,adjtime,--wrap,getdirentries,--wrap,readv,--wrap,utimes,--wrap,wait3" To build with recent cm3 compilers, this has to change to: GCWRAPFLAGS = "" The immediate symptom of this problem is link failures during building, with messages similar to undefined reference to `__wrap_utimes' -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:14:41 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:14:41 -0500 Subject: [M3devel] A note on building m3gdb Message-ID: <46C0D7D1.3000009@wichita.edu> If you don't have a working flex installed, you may get a failure trying to build m3gdb, complaining about not being able to regenerate ada-lex.c. If this happens, try doing, in the cm3 directory: touch m3-sys/m3gdb/gdb/gdb/ada-lex.c and rebuilding. -- ------------------------------------------------------------- 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 Tue Aug 14 09:43:55 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Aug 2007 09:43:55 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> On Tue, August 14, 2007 05:55, Alex Bochannek wrote: > Olaf, > > "Olaf Wagner" writes: > >> I would be surprised if that would be all; supporting other installation >> locations by the simple build scripts has really not been a target >> until now. Improvements are always welcome though, so if you have >> patches that make this abstraction they're sure to get included. > > I don't really know my way around the CM3 install scripts very well, but > I am happy to have a look and see what I can come up with. > >> cm3cg is the standard GNU compiler backend, so it may need some >> (ever increasing) infrastructure (i.e. other GNU libraries). We should >> either declare this as an explicit dependency (i.e. installation >> prerequisite) or include it in our installation archives. Probably >> it hasn't been missing for anybody else using M3 so far, because >> gcc was always installed before. > > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. Could/should I use > EZM3 to bootstrap CM3? Sounds like a good idea; we should probably add --disable-nls to our gcc configuration. I don't think it will be easy to bootstrap CM3 with EZM3 (though it should be possible); there will probably be some subtle dependencies one tends to overlook. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 16 09:03:36 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 09:03:36 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> Message-ID: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 07:37, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Sounds like a good idea; we should probably add --disable-nls to >> our gcc configuration. > > If you want to build a SOLgnu installation archive, I would be happy to > test it. > > I have been looking at building CM3 on a recent RHEL-like Linux > distribution. It seems that for the 5.4.0 release, it will build and > ship if the two known issues are taken care of (the adm/ipc.h and the > LD_POINTER_GUARD). > > However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 > installation archive seems to not be possible anymore. I followed the > email exchanges with Tony Hosking's suggested build steps and also made > the PTHREAD and GC related changes necessary to cm3.cfg. After numerous > errors due to what I think are the LONGINT changes, I gave up. I don't > really need these changes, but it looks like it might be time for > another release soon. Sure, as soon as the LONGINT changes have settled, we'll provide some new installation archives. Stefan, could you add the --disable-nls to the gcc configuration and try to build a SOLgnu archive? Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Thu Aug 16 12:22:25 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:22:25 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: <20070816102225.GA25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? Current head, 5.4, or both? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 12:59:22 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:59:22 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816102225.GA25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> Message-ID: <20070816105922.GB25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > > Stefan, could you add the --disable-nls to the gcc configuration and > > try to build a SOLgnu archive? > > Current head, 5.4, or both? Wait a minute... as far as I can tell we already build it with --disable-nls in all cases. Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk has the same): % configure the sources if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "--with-gnu-ld=yes", "&& echo \"done\" > " & done) else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--target=" & GNU_platform (M3CC_TARGET), "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end end -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Thu Aug 16 14:54:34 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 14:54:34 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816105922.GB25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> Message-ID: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 12:59, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: >> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: >> > Stefan, could you add the --disable-nls to the gcc configuration and >> > try to build a SOLgnu archive? >> >> Current head, 5.4, or both? Both :) > Wait a minute... as far as I can tell we already build it > with --disable-nls in all cases. > > Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk > has the same): > > % configure the sources > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "--with-gnu-ld=yes", > "&& echo \"done\" > " & done) > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--target=" & GNU_platform (M3CC_TARGET), > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > end Then I don't understand why the version Alex Bochannek got from our installation archives needed libiconv.so.2. Any idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Aug 16 15:42:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:42:53 -0400 Subject: [M3devel] Windows Message-ID: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> With the current native Windows backend (m3back) blindly assuming (without even checking!) that all integer operations are 32-bit, I wonder if anyone out there has the expertise, time, or inclination to smarten it up to handle both 32-bit and 64-bit ops. It should not be *too* hard, but I don't have the time for it now, though I would be happy to answer any questions that arise. Unfortunately, this reveals that Windows support is withering on the vine, in spite of Jay's excellent recent work. As of now, this means that Windows can only build CVS sources with the tag devel_LONGINT_start. Bridging the gap will require smartening up m3back or using the gcc-based backend. From stsp at elego.de Thu Aug 16 15:44:59 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 15:44:59 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> Message-ID: <20070816134458.GD25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 02:54:34PM +0200, Olaf Wagner wrote: > Then I don't understand why the version Alex Bochannek got from > our installation archives needed libiconv.so.2. Any idea? Because m3-sys/m3cc/gcc/gcc/configure.ac depends on it unconditionally. The following is in global scope: AM_ICONV # Until we have in-tree GNU iconv: LIBICONV_DEP= AC_SUBST(LIBICONV_DEP) So I guess the configure script always picks up libiconv if it is present. I'll try to remove the check for libiconv to see if the backend builds without it. The script even bothers to filter out possible multiple occurences of -liconv if --enable-nls is passed (i.e. gcc if is linked to libintl): # If LIBINTL contains LIBICONV, then clear LIBICONV so we don't get # -liconv on the link line twice. case "$LIBINTL" in *$LIBICONV*) LIBICONV= ;; esac The non-iconv case is clearly not intended by the authors of configure.ac... Also, I just checked the cm3cg binary on FreeBSD, it also depends on libiconv, which is not in the base system on FreeBSD either: % ldd /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg: libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28474000) libc.so.6 => /lib/libc.so.6 (0x28561000) -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 15:34:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:34:51 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: On Aug 16, 2007, at 3:03 AM, Olaf Wagner wrote: > On Thu, August 16, 2007 07:37, Alex Bochannek wrote: >> "Olaf Wagner" writes: >> >>> Sounds like a good idea; we should probably add --disable-nls to >>> our gcc configuration. >> >> If you want to build a SOLgnu installation archive, I would be >> happy to >> test it. I'm about to build from CVS head for SOLgnu today. I will place a bootstrap compiler (front-end and back-end) on my ftp site in the usual place. >> I have been looking at building CM3 on a recent RHEL-like Linux >> distribution. It seems that for the 5.4.0 release, it will build and >> ship if the two known issues are taken care of (the adm/ipc.h and the >> LD_POINTER_GUARD). I don't know how these issues relate to the CVS head, but I did successfully bootstrap CVS head yesterday. The compiler pieces are in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6, files cm3cg.gz and cm3.gz. >> >> However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 >> installation archive seems to not be possible anymore. I followed the >> email exchanges with Tony Hosking's suggested build steps and also >> made >> the PTHREAD and GC related changes necessary to cm3.cfg. After >> numerous >> errors due to what I think are the LONGINT changes, I gave up. I >> don't >> really need these changes, but it looks like it might be time for >> another release soon. Indeed, to bootstrap from an *old* compiler that does not handle LONGINT, you will need to build and ship in the following order: m3cc m3middle m3linker m3front m3quake cm3 Now, using the *new* stage 1 cm3 you just built (cm3/TARGET/cm3) and clean sources you can build and ship: m3core libm3 m3middle m3linker m3front m3quake cm3 With this *new* stage 2 cm3 you should be ready to build the world. > Sure, as soon as the LONGINT changes have settled, we'll provide some > new installation archives. Getting there... We really need someone to work on the *native* x86 backend m3back to smarten it up for LONGINT ... until then truly native Win32 support will be lacking (though it should be possible to build using the gcc-based backend, presumably installed and built using CygWin?). > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? I'll put a SOLgnu bootstrap compiler built from the CVS head on my ftp site later today. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From rodney.bates at wichita.edu Thu Aug 16 18:19:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 11:19:39 -0500 Subject: [M3devel] Missing .M3EXPORTS Message-ID: <46C4791B.1080207@wichita.edu> What does the following failure mean? I run into it regularly. -------------------------------------------------------------------------------------------------- rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import_version -- import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/src/m3makefile 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/LINUXLIBC6/m3make.args Fatal Error: package build failed -------------------------------------------------------------------------------------------------- Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp site into /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library locations and -gstabs to m3-link. I did a cvs update for the whole cm3 head, then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 -build and cm3 -ship. -- ------------------------------------------------------------- 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 Thu Aug 16 18:33:20 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:33:20 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4791B.1080207@wichita.edu> References: <46C4791B.1080207@wichita.edu> Message-ID: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > What does the following failure mean? I run into it regularly. > > ---------------------------------------------------------------------- > ---------------------------- > rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake > runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ > m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import_version -- > import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS > include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/src/m3makefile > 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > ---------------------------------------------------------------------- > ---------------------------- > > Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's > ftp site into > /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my > library > locations and -gstabs to m3-link. I did a cvs update for the whole > cm3 head, > then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - > build and cm3 -ship. > > -- > ------------------------------------------------------------- > 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 Thu Aug 16 18:47:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:47:36 -0400 Subject: [M3devel] Windows In-Reply-To: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> References: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> Message-ID: I should have realized of course that there is a very simple fix for compilation on the NT386 target using the native m3back backend! Simply make LONGINT=Int32. Jay, I have just checked in this very simple fix to Target.m3 which should permit you to bootstrap a new cm3 and compile the current CVS head. On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > With the current native Windows backend (m3back) blindly assuming > (without even checking!) that all integer operations are 32-bit, I > wonder if anyone out there has the expertise, time, or inclination > to smarten it up to handle both 32-bit and 64-bit ops. It should > not be *too* hard, but I don't have the time for it now, though I > would be happy to answer any questions that arise. Unfortunately, > this reveals that Windows support is withering on the vine, in > spite of Jay's excellent recent work. As of now, this means that > Windows can only build CVS sources with the tag > devel_LONGINT_start. Bridging the gap will require smartening up > m3back or using the gcc-based backend. > From hosking at cs.purdue.edu Thu Aug 16 19:13:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:13:06 -0400 Subject: [M3devel] AMD64 Message-ID: I seem to recall that someone had been working on a Linux AMD64 target. I'd like to get that working and would be interested in any progress that's been made in that direction. From stsp at elego.de Thu Aug 16 19:25:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:25:15 +0200 Subject: [M3devel] AMD64 In-Reply-To: References: Message-ID: <20070816172515.GC15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:18:13 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:18:13 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816171813.GB15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:46:55 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:46:55 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816174655.GD15579@jack.stsp.lan> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. I'd favour listing libiconv as an explicit dependency of cm3. I've looked into this, and --disable-nls is not sufficient to remove gcc's dependency on libiconv. It unconditionally depends on libiconv if it can find the library on the system, regardless of flags passed to the configure script. I've tried hacking iconv detection out of the build system. There's a diff below against cm3-5.4 that removes cm3cg's dependency on libiconv. But it is very ugly. m3gdb also unconditionally depends on libiconv. I have not looked into that. I cannot deinstall libiconv on our Solaris box to prevent configure from picking it up because I don't have root, and I don't really think it's a good idea to begin with because removing the library would probably break a lot of dependencies. Alex, could you provide more details on what gcc backend you are using? Does the ezm3 equivalent of the cm3cg executable depend on libiconv? % ldd /usr/local/cm3/bin/cm3cg libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 With the patch below I get: % ldd /usr/stsp/cm3/bin/cm3cg libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 Index: src/m3makefile =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 m3makefile --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 @@ -126,7 +126,8 @@ if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." + & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", Index: gcc/gcc/Makefile.in =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 @@ -471,8 +471,8 @@ LIBINTL_DEP = @LIBINTL_DEP@ # Character encoding conversion library. -LIBICONV = @LIBICONV@ -LIBICONV_DEP = @LIBICONV_DEP@ +#LIBICONV = @LIBICONV@ +#LIBICONV_DEP = @LIBICONV_DEP@ # The GC method to be used on this system. GGC=@GGC at .o @@ -718,7 +718,7 @@ BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a # Dependencies on the intl and portability libraries. -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) # Likewise, for use in the tools that must run on this machine # even if we are cross-building GCC. @@ -726,7 +726,7 @@ # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:49:56 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:49:56 +0200 Subject: [M3devel] AMD64 In-Reply-To: <20070816172515.GC15579@jack.stsp.lan> References: <20070816172515.GC15579@jack.stsp.lan> Message-ID: <20070816174956.GE15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 07:25:15PM +0200, Stefan Sperling wrote: > <<< No Message Collected >>> > --oTHb8nViIGeoXxdp-- Sorry, local sendmail screw up. Manually messing with the mail queue is not a good idea :-/ Here is the message again: On Thu, Aug 16, 2007 at 01:13:06PM -0400, Tony Hosking wrote: > I seem to recall that someone had been working on a Linux AMD64 target. > I'd like to get that working and would be interested in any progress that's > been made in that direction. That was me. It was more than 2 years ago. The problem back then was that the gcc backend kept segfaulting while trying to bootstrap a native cm3 for amd64. The front end is pretty much done iirc. We anticipated an update of the backend to see if that would fix things. Since you've done the update long ago at this stage, I guess it's worth trying to merge the diff into the current tree, minus the now obsolete system call wrappers in the diff. Maybe things just work. The diff is here: http://www.stsp.name/cm3/cm3-linux-amd64-2005-04-18.patch -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 19:53:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:53:42 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816174655.GD15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> Message-ID: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> I just built cm3cg on SPARC: hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 hosking at arthur ~-> No libiconv... The bootstrap compiler (cm3) and backend (cm3cg) are available at ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and cm3cg.gz. These are both built from the CVS head and contain LONGINT support. On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >> Is it possible to configure it with --disable-nls? That's what we >> tend >> to do for our GCC builds as well. I just looked at the EZM3 >> install we >> have and it doesn't seem like it requires libiconv. > > I'd favour listing libiconv as an explicit dependency of cm3. > > I've looked into this, and --disable-nls is not sufficient to remove > gcc's dependency on libiconv. It unconditionally depends on libiconv > if it can find the library on the system, regardless of flags passed > to the configure script. > > I've tried hacking iconv detection out of the build system. > There's a diff below against cm3-5.4 that removes cm3cg's > dependency on libiconv. But it is very ugly. > > m3gdb also unconditionally depends on libiconv. > I have not looked into that. > > I cannot deinstall libiconv on our Solaris box to prevent configure > from picking it up because I don't have root, and I don't really think > it's a good idea to begin with because removing the library would > probably break a lot of dependencies. > > Alex, could you provide more details on what gcc backend you are > using? > Does the ezm3 equivalent of the cm3cg executable depend on libiconv? > > > % ldd /usr/local/cm3/bin/cm3cg > libiconv.so.2 => /usr/local/lib/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > With the patch below I get: > > % ldd /usr/stsp/cm3/bin/cm3cg > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > > Index: src/m3makefile > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v > retrieving revision 1.16.2.1 > diff -u -r1.16.2.1 m3makefile > --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 > +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 > @@ -126,7 +126,8 @@ > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & > "configure", > + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." > + & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > Index: gcc/gcc/Makefile.in > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v > retrieving revision 1.6 > diff -u -r1.6 Makefile.in > --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 > +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 > @@ -471,8 +471,8 @@ > LIBINTL_DEP = @LIBINTL_DEP@ > > # Character encoding conversion library. > -LIBICONV = @LIBICONV@ > -LIBICONV_DEP = @LIBICONV_DEP@ > +#LIBICONV = @LIBICONV@ > +#LIBICONV_DEP = @LIBICONV_DEP@ > > # The GC method to be used on this system. > GGC=@GGC at .o > @@ -718,7 +718,7 @@ > BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a > > # Dependencies on the intl and portability libraries. > -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) > +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) > > # Likewise, for use in the tools that must run on this machine > # even if we are cross-building GCC. > @@ -726,7 +726,7 @@ > > # How to link with both our special library facilities > # and the system's installed libraries. > -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) > +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) > > # Any system libraries needed just for GNAT. > SYSLIBS = @GNAT_LIBEXC@ > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From hosking at cs.purdue.edu Thu Aug 16 19:54:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:54:55 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: PS Here is how I configured building in m3cc/SOLgnu: ../gcc/configure --enable-languages=m3cg --disable-nls On Aug 16, 2007, at 1:53 PM, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... > > The bootstrap compiler (cm3) and backend (cm3cg) are available at > ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and > cm3cg.gz. These are both built from the CVS head and contain > LONGINT support. > > > On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > >> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >>> Is it possible to configure it with --disable-nls? That's what we >>> tend >>> to do for our GCC builds as well. I just looked at the EZM3 >>> install we >>> have and it doesn't seem like it requires libiconv. >> >> I'd favour listing libiconv as an explicit dependency of cm3. >> >> I've looked into this, and --disable-nls is not sufficient to remove >> gcc's dependency on libiconv. It unconditionally depends on libiconv >> if it can find the library on the system, regardless of flags passed >> to the configure script. >> >> I've tried hacking iconv detection out of the build system. >> There's a diff below against cm3-5.4 that removes cm3cg's >> dependency on libiconv. But it is very ugly. >> >> m3gdb also unconditionally depends on libiconv. >> I have not looked into that. >> >> I cannot deinstall libiconv on our Solaris box to prevent configure >> from picking it up because I don't have root, and I don't really >> think >> it's a good idea to begin with because removing the library would >> probably break a lot of dependencies. >> >> Alex, could you provide more details on what gcc backend you are >> using? >> Does the ezm3 equivalent of the cm3cg executable depend on libiconv? >> >> >> % ldd /usr/local/cm3/bin/cm3cg >> libiconv.so.2 => /usr/local/lib/libiconv.so.2 >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> With the patch below I get: >> >> % ldd /usr/stsp/cm3/bin/cm3cg >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> >> Index: src/m3makefile >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v >> retrieving revision 1.16.2.1 >> diff -u -r1.16.2.1 m3makefile >> --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 >> +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 >> @@ -126,7 +126,8 @@ >> if stale(donep, donep) >> if equal (M3CC_HOST, M3CC_TARGET) >> if equal (M3CC_TARGET, "SOLgnu") >> - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & >> "configure", >> + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." >> + & SL & "gcc" & SL & "configure", >> M3CC_CONFIG, >> "--srcdir=.." & SL & "gcc", >> "--enable-languages=m3cg", >> Index: gcc/gcc/Makefile.in >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v >> retrieving revision 1.6 >> diff -u -r1.6 Makefile.in >> --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 >> +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 >> @@ -471,8 +471,8 @@ >> LIBINTL_DEP = @LIBINTL_DEP@ >> >> # Character encoding conversion library. >> -LIBICONV = @LIBICONV@ >> -LIBICONV_DEP = @LIBICONV_DEP@ >> +#LIBICONV = @LIBICONV@ >> +#LIBICONV_DEP = @LIBICONV_DEP@ >> >> # The GC method to be used on this system. >> GGC=@GGC at .o >> @@ -718,7 +718,7 @@ >> BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a >> >> # Dependencies on the intl and portability libraries. >> -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) >> +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) >> >> # Likewise, for use in the tools that must run on this machine >> # even if we are cross-building GCC. >> @@ -726,7 +726,7 @@ >> >> # How to link with both our special library facilities >> # and the system's installed libraries. >> -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) >> +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) >> >> # Any system libraries needed just for GNAT. >> SYSLIBS = @GNAT_LIBEXC@ >> >> -- >> Stefan Sperling Software Developer >> elego Software Solutions GmbH HRB 77719 >> Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 >> 13355 Berlin Fax: +49 30 23 45 86 95 >> http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > From stsp at elego.de Thu Aug 16 19:59:30 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:59:30 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816175930.GG15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... Is that because you don't have libiconv installed on your system? -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:10:04 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 20:10:04 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816181004.GH15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:54:55PM -0400, Tony Hosking wrote: > PS Here is how I configured building in m3cc/SOLgnu: > > ../gcc/configure --enable-languages=m3cg --disable-nls --disable-nls makes no difference at all with respect to libiconv. See my previous mail. All --disable-nls does is remove a dependency on libintl. This is not a Solaris-only problem. We can either: 1) Build cm3 releases on boxes that haven't got libiconv installed. 2) Declare libiconv an official dependency of cm3. 3) Hack the dependency on libiconv out of the build systems of cm3cg and m3gdb, and possibly others. 1) is a pain for people making releases. 2) is easy for developers, and nothing changes for users because we've always implicitly depended on libiconv without noticing. I've posted a crude patch that does 3) for cm3cg, but not for m3gdb. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 20:28:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 14:28:56 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816175930.GG15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <20070816175930.GG15579@jack.stsp.lan> Message-ID: On Aug 16, 2007, at 1:59 PM, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: >> I just built cm3cg on SPARC: >> >> hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg >> libc.so.1 => /usr/lib/libc.so.1 >> libdl.so.1 => /usr/lib/libdl.so.1 >> /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 >> hosking at arthur ~-> >> >> No libiconv... > > Is that because you don't have libiconv installed on your system? Hmm. The version of gcc I built cm3cg with was bootstrapped from a configuration: ../gcc/configure --prefix=/p/sss/gcc-4.1 --enable-languages=c On inspection, it appears that there is no libiconv installed in /p/ sss/gcc-4.1/lib. hosking at arthur ~-> ls -l /p/sss/gcc-4.1/lib total 2280 drwxr-sr-x 3 hosking sssadmin 4096 Aug 16 12:48 gcc/ lrwxrwxrwx 1 hosking sssadmin 13 Aug 16 12:49 libgcc_s.so -> libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 234060 Aug 16 12:49 libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 816456 Aug 16 12:49 libiberty.a -rw-r--r-- 1 hosking sssadmin 47164 Aug 16 12:49 libssp.a -rwxr-xr-x 1 hosking sssadmin 732 Aug 16 12:49 libssp.la* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so -> libssp.so.0.0.0* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so.0 -> libssp.so.0.0.0* -rwxr-xr-x 1 hosking sssadmin 29060 Aug 16 12:49 libssp.so.0.0.0* -rw-r--r-- 1 hosking sssadmin 2200 Aug 16 12:49 libssp_nonshared.a -rwxr-xr-x 1 hosking sssadmin 714 Aug 16 12:49 libssp_nonshared.la* drwxr-sr-x 2 hosking sssadmin 4096 Aug 16 12:49 sparcv9/ hosking at arthur ~-> > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From rodney.bates at wichita.edu Thu Aug 16 22:49:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 15:49:08 -0500 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Message-ID: <46C4B844.3080901@wichita.edu> No, I hadn't, but it didn't help. Note it is in m3core that the .M3EXPORTS is not found, while I was trying to compile in m3middle. In any case, it should be normal to do a compile in a directory that has a partially populated LINUXLIBC6 (or whatever), expecting the compiler to figure out what to do. I tried departing from the listed order and building/shipping m3core and libm3, before m3middle, and that got the bootstrap going. These did not have a LINUXLIBC6 directory, I suppose because of the realclean. Tony Hosking wrote: > Did you "rm -rf LINUXLIBC6" before "cm3 -build"? > > On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > >> What does the following failure mean? I run into it regularly. >> >> ---------------------------------------------------------------------- >> ---------------------------- >> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ >> m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >> >> --procedure-- -line- -file--- >> import_version -- >> import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS >> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/src/m3makefile >> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/LINUXLIBC6/m3make.args >> >> Fatal Error: package build failed >> >> ---------------------------------------------------------------------- >> ---------------------------- >> >> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp >> site into >> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library >> locations and -gstabs to m3-link. I did a cvs update for the whole >> cm3 head, >> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - build >> and cm3 -ship. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 16 23:19:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 16:19:08 -0500 Subject: [M3devel] A strange link time warning using cm3 Message-ID: <46C4BF4C.9070706@wichita.edu> When linking a program of my own, using cm3 from the cvs head, I get this warning: ----------------------------------------------------------------------------------------------------- -> linking LdlBatch /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In function `TrestleOS__UserName': /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ----------------------------------------------------------------------------------------------------- And a few more just like it. This doesn't make any sense to me. If a "statically linked application" is what it says it is, why would it require at runtime, any shared library at all, let alone a specific version? -- ------------------------------------------------------------- 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 Thu Aug 16 23:26:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 17:26:47 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4B844.3080901@wichita.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> <46C4B844.3080901@wichita.edu> Message-ID: Sounds like you are getting overrides or something. Certainly is strange behavior, which I don't see. On Aug 16, 2007, at 4:49 PM, Rodney M. Bates wrote: > No, I hadn't, but it didn't help. Note it is in m3core that the > .M3EXPORTS is not found, while I was trying to compile in m3middle. > > In any case, it should be normal to do a compile in a directory > that has a partially populated LINUXLIBC6 (or whatever), expecting > the compiler to figure out what to do. > > I tried departing from the listed order and building/shipping > m3core and libm3, before m3middle, and that got the bootstrap > going. These did not have a LINUXLIBC6 directory, I suppose > because of the realclean. > > Tony Hosking wrote: >> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? >> On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: >>> What does the following failure mean? I run into it regularly. >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >>> --- building in LINUXLIBC6 --- >>> >>> ignoring ../src/m3overrides >>> >>> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >>> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/ >>> cm3/ m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >>> >>> --procedure-- -line- -file--- >>> import_version -- >>> import 4 /usr/local/cm3/pkg/libm3/ >>> LINUXLIBC6/.M3EXPORTS >>> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/src/m3makefile >>> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/LINUXLIBC6/m3make.args >>> >>> Fatal Error: package build failed >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> >>> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's >>> ftp site into >>> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my >>> library >>> locations and -gstabs to m3-link. I did a cvs update for the >>> whole cm3 head, >>> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - >>> build and cm3 -ship. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From roland.illig at gmx.de Fri Aug 17 00:26:48 2007 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 17 Aug 2007 00:26:48 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <46C4CF28.8090001@gmx.de> Rodney M. Bates wrote: > This doesn't make any sense to me. If a "statically linked > application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? The user, group, host, whatever databases uses a plug-in mechanism on Linux (something called nsswitch or similar). The plug-ins can be an SQL database, LDAP, PAM, traditional password files and so on. Since the exact set of plug-ins is not known at compile-time, shared libraries must be used in this case. Roland From wagner at elegosoft.com Fri Aug 17 09:54:42 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 09:54:42 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 23:19, Rodney M. Bates wrote: > When linking a program of my own, using cm3 from the cvs head, I get this > warning: > ----------------------------------------------------------------------------------------------------- > -> linking LdlBatch > /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In > function > `TrestleOS__UserName': > /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: > warning: Using 'getpwuid' in > statically linked applications requires at runtime the shared libraries from > the glibc version used > for linking > ----------------------------------------------------------------------------------------------------- > > And a few more just like it. This doesn't make any sense to me. If a > "statically > linked application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? As Roland Illig already pointed out, modern operating systems don't really support traditional static linking if you are using certain functionality (which accidentally is needed by almost all programs ;-). Nonetheless the warnings you get point to a problem with the CM3 setup: those libraries that need to be plugged-in by the OS must not be linked statically. In cm3.cfg the set up system libraries should be separated into those that need dynamic linking and others. All system libraries that need dynamic linking should be linked this way, regardless of the cm3 arguments. This way `statically linked' refers only to the CM3 libraries and not to the -- always available -- operating system libraries, and can still be a help for delivering independent programs written in M3. Stefan, I thought we had resolved this issue at least for Linux and Solaris setups with the last release. Did we miss something? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Aug 17 14:19:02 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 17 Aug 2007 14:19:02 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> Message-ID: <20070817121902.GB10092@jack.stsp.lan> On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: > Stefan, I thought we had resolved this issue at least for Linux and > Solaris setups with the last release. Did we miss something? We link system libraries dynamically on these platforms. It could be that Rodney's own program does not link libraries dynamically, so he gets the warning. This is the diff that introduced dynamic linking on Linux. Note that we explicitly enable dynamic linking on a per-library basis... maybe we should enforce dynamic linking in general? Index: LINUXLIBC6 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cm3/src/config/LINUXLIBC6,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- LINUXLIBC6 6 Aug 2006 12:46:03 -0000 1.7 +++ LINUXLIBC6 1 Sep 2006 13:42:23 -0000 1.8 @@ -98,14 +98,14 @@ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], -% "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms - "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], - "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], - "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], - "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], - "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", +% "LEX-YACC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-ll" ], %-- not on most Linux platforms + "FLEX-BISON" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lfl" ], + "POSTGRES95" : [ "-Xlinker", "-Bdynamic", "-L/usr/local/postgres95/lib", "-lpq" ], + "OPENGL" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], + "MOTIF" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXm" ], + "X11" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], - "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], + "PTHREAD" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Aug 17 14:54:04 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 14:54:04 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <20070817121902.GB10092@jack.stsp.lan> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> Message-ID: <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> Stefan, I thought we had resolved this issue at least for Linux and >> Solaris setups with the last release. Did we miss something? > > We link system libraries dynamically on these platforms. > > It could be that Rodney's own program does not link > libraries dynamically, so he gets the warning. > > This is the diff that introduced dynamic linking on Linux. > Note that we explicitly enable dynamic linking on a per-library > basis... maybe we should enforce dynamic linking in general? [diff removed] No, I only want to find out why Rodney gets those warnings. Either he hasn't the cm3.cfg changes from the last release, or some other packages (Trestle?) import more libraries which cause the problem. Rodney, could you please check that? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Aug 17 22:26:02 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 17 Aug 2007 15:26:02 -0500 Subject: [M3devel] A strange link time warning using cm3] Message-ID: <46C6045A.6050402@wichita.edu> I usually just manually edit my old cm3.cfg files, because I usually have to merge my local library locations, etc. And I haven't done a cminstall in a while. So I don't have the official version. Right now, I have none of the libraries dynamically linked. I just didn't realize there were some of them that would not work on. From my cm3.cfg on the machine where I got the quoted message (running Linux Mandrake 10.2): ------------------------------------------------------------------------ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } ------------------------------------------------------------------------ Even so, the warning only happens when I compile a program with build_standalone ( ) in the m3makefile. I guess I'll put back the -Xlinker -Bdynamic in the libraries that Stefan's diff shows. Will this change anything other than getting rid of the warning message? After I read about dynamic linking in the 60's on the Multics system, I always thought it was a great idea. After decades of waiting, I gave up ever seeing it in anything but a research OS. Now that it has become universal, I have often wondered if we would be better to put that genie back in the bottle. Library version skew, when moving from machine to machine can be a nightmare, even when your OS does allow multiple versions to be installed simultaneously. But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. Olaf Wagner wrote: > On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > >>On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> >>>Stefan, I thought we had resolved this issue at least for Linux and >>>Solaris setups with the last release. Did we miss something? >> >>We link system libraries dynamically on these platforms. >> >>It could be that Rodney's own program does not link >>libraries dynamically, so he gets the warning. >> >>This is the diff that introduced dynamic linking on Linux. >>Note that we explicitly enable dynamic linking on a per-library >>basis... maybe we should enforce dynamic linking in general? > > [diff removed] > > No, I only want to find out why Rodney gets those warnings. > Either he hasn't the cm3.cfg changes from the last release, or > some other packages (Trestle?) import more libraries which cause > the problem. Rodney, could you please check that? > > Olaf -- ------------------------------------------------------------- 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 rcoleburn at scires.com Fri Aug 17 23:26:20 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Aug 2007 17:26:20 -0400 Subject: [M3devel] A strange link time warning using cm3] In-Reply-To: <46C6045A.6050402@wichita.edu> References: <46C6045A.6050402@wichita.edu> Message-ID: <46C5DA31.1E75.00D7.1@scires.com> >>> "Rodney M. Bates" rodney.bates at wichita.edu> 8/17/2007 4:26 PM >> ( mailto:rodney.bates at wichita.edu> ) .... But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. .... I thought that the buildstandalone() directive in the m3makefile is supposed to cause linking with static libraries. At least that is what happens in cm3 v4.1. Regards, Randy Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Aug 18 02:47:36 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 02:47:36 +0200 Subject: [M3devel] strange... Message-ID: <1187398056.31487.17.camel@faramir.m3w.org> I am getting this... No idea where it gosts imported, and being so late here... Maybe I can find answer when I woke :). TIA. As far as I know, this is full boostrap by latest instructions from cvshead over earlier revision. ... -> linking hcca /usr/bin/ld: cannot find -lm3gcdefs collect2: ld returned 1 exit status Fatal Error: package build failed -- Dragi?a Duri? From jayk123 at hotmail.com Sat Aug 18 04:37:22 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 18 Aug 2007 02:37:22 +0000 Subject: [M3devel] Windows Message-ID: I have the inclination, still working on time and expertise. :) Summarize the layering for me? Which module calls which?Your mention below of the assumption of 32 bit ops at least confirms what I thought I vaguely understood reading through the source. It's just a bunch of pretty dense code without documentation, the sort I write myself when I have the whole program in my head and just need to type it all in as quickly as possible. Would the idea be to use a tagged union for this stack, or to split 64 bits ops into pairs of 32 bit ops? You know, like, does this stack translate "closely" to the generated code, or not? If it does, pairs, if it does not, tagged union. Probably. Similarly, like, all the register dealings need some notion of pairs..? Maybe I should look at the other backend to understand better, if there is an analogous bunch of code. Anyway, I'll try at least this weekend to verify that it's buildable asis, i know that's just a teeny tiny baby step, just push the button to build, a monkey could do it... my expertise is beyond that, but... I suspect tagged union is it, and have to churn a bunch of code to check the type. ugh. lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 bit type). ?? Thanks, - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: Windows> Date: Thu, 16 Aug 2007 12:47:36 -0400> To: jay.krell at cornell.edu; jayk123 at hotmail.com> > I should have realized of course that there is a very simple fix for > compilation on the NT386 target using the native m3back backend! > Simply make LONGINT=Int32. Jay, I have just checked in this very > simple fix to Target.m3 which should permit you to bootstrap a new > cm3 and compile the current CVS head.> > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote:> > > With the current native Windows backend (m3back) blindly assuming > > (without even checking!) that all integer operations are 32-bit, I > > wonder if anyone out there has the expertise, time, or inclination > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > not be *too* hard, but I don't have the time for it now, though I > > would be happy to answer any questions that arise. Unfortunately, > > this reveals that Windows support is withering on the vine, in > > spite of Jay's excellent recent work. As of now, this means that > > Windows can only build CVS sources with the tag > > devel_LONGINT_start. Bridging the gap will require smartening up > > m3back or using the gcc-based backend.> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 18 11:52:52 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Aug 2007 11:52:52 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C5C599.9010306@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> <46C5C599.9010306@wichita.edu> Message-ID: <20070818095252.GA10785@elegosoft.com> On Fri, Aug 17, 2007 at 10:58:17AM -0500, Rodney M. Bates wrote: > I usually just manually edit my old cm3.cfg files, because I usually > have to merge my local library locations, etc. And I haven't done a > cminstall in a while. So I don't have the official version. > > Right now, I have none of the libraries dynamically linked. I just > didn't realize there were some of them that would not work on. > > From my cm3.cfg on the machine where I got the quoted message > (running Linux Mandrake 10.2): > > ------------------------------------------------------------------------ > SYSTEM_LIBS = { > "LIBC" : [ "-lm" ], > % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms > "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], > "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], > "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], > "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], > "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", > "-lXt", "-lSM", "-lICE", "-lX11" ], > "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], > "TCP" : [ ] > } > ------------------------------------------------------------------------ OK, so you're just missing the dynamic hints in the linker setup. Could you please verify that that's all and we've found everything that needs to be linker dynamically unconditionally? > Even so, the warning only happens when I compile a program with > build_standalone ( ) in the m3makefile. The default has long been to link dynamically; build_standalone should switch to static linking wherever possible. > I guess I'll put back the -Xlinker -Bdynamic in the libraries that > Stefan's diff shows. Will this change anything other than getting > rid of the warning message? I hope not. > > After I read about dynamic linking in the 60's on the Multics system, > I always thought it was a great idea. After decades of waiting, I gave > up ever seeing it in anything but a research OS. Now that it has become > universal, I have often wondered if we would be better to put that genie > back in the bottle. Library version skew, when moving from machine to > machine can be a nightmare, even when your OS does allow multiple versions > to be installed simultaneously. But at least, I thought, the option to do > full static linking was still there, for those who chose it. So it is a > bit of a shock to learn that that option is now gone. > I'm with you there; I experienced the same feeling some years ago :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sat Aug 18 19:35:17 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 19:35:17 +0200 Subject: [M3devel] strange... And also some CM3isms In-Reply-To: <1187398056.31487.17.camel@faramir.m3w.org> References: <1187398056.31487.17.camel@faramir.m3w.org> Message-ID: <1187458517.31487.21.camel@faramir.m3w.org> One of packages was left behind while rebuilding... Of course there is no m3gcdefs in cm4 cvshead... Long ago I remember reading about runtime errors being exceptions (in CM3) and also RETURN and EXIT.... Is there some example code on how to use this? On Sat, 2007-08-18 at 02:47 +0200, Dragi?a Duri? wrote: > I am getting this... No idea where it gosts imported, and being so late > here... Maybe I can find answer when I woke :). TIA. > > As far as I know, this is full boostrap by latest instructions from > cvshead over earlier revision. > > ... > -> linking hcca > /usr/bin/ld: cannot find -lm3gcdefs > collect2: ld returned 1 exit status > Fatal Error: package build failed > -- Dragi?a Duri? From hosking at cs.purdue.edu Sat Aug 18 22:18:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Aug 2007 16:18:09 -0400 Subject: [M3devel] Windows In-Reply-To: References: Message-ID: <835F3374-48D2-4785-A82B-87792B1A483C@cs.purdue.edu> On Aug 17, 2007, at 10:37 PM, j k wrote: > I have the inclination, still working on time and expertise. :) > Summarize the layering for me? Which module calls which? > Your mention below of the assumption of 32 bit ops at least > confirms what I thought I vaguely understood reading through the > source. It's just a bunch of pretty dense code without > documentation, the sort I write myself when I have the whole > program in my head and just need to type it all in as quickly as > possible. Would the idea be to use a tagged union for this stack, > or to split 64 bits ops into pairs of 32 bit ops? > You know, like, does this stack translate "closely" to the > generated code, or not? If it does, pairs, if it does not, tagged > union. Probably. Similarly, like, all the register dealings need > some notion of pairs..? Maybe I should look at the other backend to > understand better, if there is an analogous bunch of code. You'll notice that the M3CG interface has many ops that take ZType= [Int32, Word32, Int64, Word64]. Unfortunatly M3x86.m3 and Stackx86.m3 simply drop those types on the floor (or simply distinguishes Word32 from Int32). I don't know the m3back code well at all, so I have no idea how tough it might be to smarten it up for Int64/Word64. > Anyway, I'll try at least this weekend to verify that it's > buildable asis, i know that's just a teeny tiny baby step, just > push the button to build, a monkey could do it... my expertise is > beyond that, but... Should be fine now, though INTEGER and LONGINT are both 32-bits for NT386 target. > > I suspect tagged union is it, and have to churn a bunch of code to > check the type. ugh. > lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 > bit type). Not sure... > > ?? > > Thanks, > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: Windows > > Date: Thu, 16 Aug 2007 12:47:36 -0400 > > To: jay.krell at cornell.edu; jayk123 at hotmail.com > > > > I should have realized of course that there is a very simple fix for > > compilation on the NT386 target using the native m3back backend! > > Simply make LONGINT=Int32. Jay, I have just checked in this very > > simple fix to Target.m3 which should permit you to bootstrap a new > > cm3 and compile the current CVS head. > > > > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > > > > > With the current native Windows backend (m3back) blindly assuming > > > (without even checking!) that all integer operations are 32-bit, I > > > wonder if anyone out there has the expertise, time, or inclination > > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > > not be *too* hard, but I don't have the time for it now, though I > > > would be happy to answer any questions that arise. Unfortunately, > > > this reveals that Windows support is withering on the vine, in > > > spite of Jay's excellent recent work. As of now, this means that > > > Windows can only build CVS sources with the tag > > > devel_LONGINT_start. Bridging the gap will require smartening up > > > m3back or using the gcc-based backend. > > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Mon Aug 20 14:01:23 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 20 Aug 2007 14:01:23 +0200 Subject: [M3devel] subrange or enum, with cvshead Message-ID: <1187611284.31487.42.camel@faramir.m3w.org> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 (skipping m3gdb, which I've reported earlier would not compile for me) I am getting this error when I try to rn one of programs that worked flawlessy few checkouts ago. *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** This is corresponding code: now := Time.Now() - epoch; >>> time := TRUNC(now); fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, LONGREAL), 8)); I've identified few other problems, but I suppose ther are all variations... -- Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:46:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:46:24 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: Hmmm. Are you using the most recent cm3cg, and a compiler bootstrapped with it? Also, I have not tested the LONGINT stuff extensively on AMD64 yet. Any chance you can diagnose the problem? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:59:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:59:19 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: I think I've tracked this down to Time.Now returning 0. Hmmm. How could this be? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:04:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:04:49 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187635746.31487.50.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> Message-ID: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> I've figured out the cure, but don't know why the problem exists. It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE constants when built on AMD64, unless it is configured as: CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls --enable-targets=x86-linux If you omit CC="gcc -m32" then the problem arises. I have put my AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and do not represent a complete 64-bit port to AMD64. See cm3.cfg, cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6- AMD64. On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > I've bootstrapped it same way as on ix86, first m3cc...cm3, then > setting > CM3 env var, then std build... > > When I just rsynced my INSTALL_ROOT and built binaries... it works, of > course. > > As for Time.Now()... I have few other problems happening... Do you > have > some kind of test code for LONGINT I can run on this AMD64 box? > > dd > > On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >> Hmmm. Are you using the most recent cm3cg, and a compiler >> bootstrapped with it? >> >> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >> Any chance you can diagnose the problem? >> >> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >> >>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>> (skipping >>> m3gdb, which I've reported earlier would not compile for me) I am >>> getting this error when I try to rn one of programs that worked >>> flawlessy few checkouts ago. >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>> *** >>> >>> This is corresponding code: >>> >>> now := Time.Now() - epoch; >>>>>> time := TRUNC(now); >>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>> LONGREAL), 8)); >>> >>> I've identified few other problems, but I suppose ther are all >>> variations... >>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:30:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:30:43 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> Message-ID: <27A835EB-4FA5-49B6-A30B-900361904CEF@cs.purdue.edu> PS I've successfully bootstrapped 32-bit LINUXLIBC6 on AMD64 and run mentor Bresenham using the bottstrap binaries from my ftp site. On Aug 20, 2007, at 7:04 PM, Tony Hosking wrote: > I've figured out the cure, but don't know why the problem exists. > It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE > constants when built on AMD64, unless it is configured as: > > CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable- > nls --enable-targets=x86-linux > > If you omit CC="gcc -m32" then the problem arises. I have put my > AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the > directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, > and do not represent a complete 64-bit port to AMD64. See cm3.cfg, > cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ > LINUXLIBC6-AMD64. > > On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > >> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >> setting >> CM3 env var, then std build... >> >> When I just rsynced my INSTALL_ROOT and built binaries... it >> works, of >> course. >> >> As for Time.Now()... I have few other problems happening... Do you >> have >> some kind of test code for LONGINT I can run on this AMD64 box? >> >> dd >> >> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>> Hmmm. Are you using the most recent cm3cg, and a compiler >>> bootstrapped with it? >>> >>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>> Any chance you can diagnose the problem? >>> >>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>> >>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>> (skipping >>>> m3gdb, which I've reported earlier would not compile for me) I am >>>> getting this error when I try to rn one of programs that worked >>>> flawlessy few checkouts ago. >>>> >>>> *** >>>> *** runtime error: >>>> *** An enumeration or subrange value was out of range. >>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>> *** >>>> >>>> This is corresponding code: >>>> >>>> now := Time.Now() - epoch; >>>>>>> time := TRUNC(now); >>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>> LONGREAL), 8)); >>>> >>>> I've identified few other problems, but I suppose ther are all >>>> variations... >>>> >>>> -- >>>> Dragi?a Duri? >>> >> -- >> Dragi?a Duri? > From wagner at elegosoft.com Tue Aug 21 08:57:47 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Aug 2007 08:57:47 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> On Tue, August 21, 2007 05:07, Alex Bochannek wrote: > I finally got around to completing a successful buildship on Solaris 10 > on SPARC. Here are the steps I did. > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) Without haveing investigated any of the issues above -- all this sounds to me like you are using a quite old Solaris system. I'd like to see the exact versions you and Tony use to build the software (uname -a). At least it might be a different worth to docuement. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Aug 21 15:54:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:54:09 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187674684.31487.54.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> <1187674684.31487.54.camel@faramir.m3w.org> Message-ID: <0558ABE2-AEB9-42F0-8E62-A5B0A3E74BE7@cs.purdue.edu> I generally skip m3gdb. I haven't tried it on AMD64. On Aug 21, 2007, at 1:38 AM, Dragi?a Duri? wrote: > Can this be a problem with m3gdb not building, LINUXLIBC6 target on > AMD64? Is it built on your machine? > > dd > > On Mon, 2007-08-20 at 19:04 -0400, Tony Hosking wrote: >> I've figured out the cure, but don't know why the problem exists. It >> seems that the gcc-based backend builds incorrect FLOAT/DOUBLE >> constants when built on AMD64, unless it is configured as: >> >> CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls >> --enable-targets=x86-linux >> >> If you omit CC="gcc -m32" then the problem arises. I have put my >> AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the >> directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and >> do not represent a complete 64-bit port to AMD64. See cm3.cfg, >> cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ >> LINUXLIBC6- >> AMD64. >> >> On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: >> >>> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >>> setting >>> CM3 env var, then std build... >>> >>> When I just rsynced my INSTALL_ROOT and built binaries... it >>> works, of >>> course. >>> >>> As for Time.Now()... I have few other problems happening... Do you >>> have >>> some kind of test code for LONGINT I can run on this AMD64 box? >>> >>> dd >>> >>> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>>> Hmmm. Are you using the most recent cm3cg, and a compiler >>>> bootstrapped with it? >>>> >>>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>>> Any chance you can diagnose the problem? >>>> >>>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>>> >>>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>>> (skipping >>>>> m3gdb, which I've reported earlier would not compile for me) I am >>>>> getting this error when I try to rn one of programs that worked >>>>> flawlessy few checkouts ago. >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>>> *** >>>>> >>>>> This is corresponding code: >>>>> >>>>> now := Time.Now() - epoch; >>>>>>>> time := TRUNC(now); >>>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>>> LONGREAL), 8)); >>>>> >>>>> I've identified few other problems, but I suppose ther are all >>>>> variations... >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 15:59:01 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:59:01 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> On Aug 20, 2007, at 11:07 PM, Alex Bochannek wrote: > I finally got around to completing a successful buildship on > Solaris 10 > on SPARC. Here are the steps I did. > > o Downloaded cm3-min-POSIX-SOLgnu-5.4.0.tgz and do a cminstall as root > into /usr/local/cm3 > > o In the process, some of the libraries it couldn't find I chose to > ignore (e.g., {PostgreSQL) > > o Downloaded the SOLgnu/cm3.gz and cm3cg.gz from Tony Hosking's site > > o Copied them over the existing ones in /usr/local/cm3 > > o Checked out a top-of-tree CVS version of cm3-src > > o Adjusted Tony's cm3.cfg to my INSTALL_ROOT > > o Did a scripts/do-cm3-core.sh buildship as root > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a > GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and > since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. Which file chokes? Is it because your m3cc is configured to use GNU as? > > o do-cm3-core.sh completed and I did an install-cm3-compiler.sh > upgrade, > again as root since it's writing it into /usr/local/cm3 > > o Finally, did a do-cm3-std.sh buildship, which ran for quite a while. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) > > o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh > buildship again. > > o The compile and install succeeded and I now have a nice new > cm3-d5.5.0. > > o Compiler some stuff in m3-games, just to make sure it really > works and > it looks like I am OK for now. I do see a number of core dumps > though > with some of apps, but I am not going to debug that at this point. What's core dumping? Is this from before my fixes to thread stopping yesterday? > > Thanks for the help and if there is anything I can do to help with > troubleshooting some of the problems on Solaris, I am happy to do so. > > Alex. > > > > Gdb compile error: > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function version.c > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/ > valops.c > In file included from ../../gdb/gdb/m3-lang.h:23, > from ../../gdb/gdb/valops.c:47: > /usr/include/stdbool.h:42:2: #error "Use of is valid > only in a c99 compilation environment." > In file included from ../../gdb/gdb/valops.c:47: > ../../gdb/gdb/m3-lang.h:34: error: syntax error before > "processing_pm3_compilation" > ../../gdb/gdb/m3-lang.h:34: warning: type defaults to `int' in > declaration of `processing_pm3_compilation' > ../../gdb/gdb/m3-lang.h:34: warning: data definition has no type or > storage class > ../../gdb/gdb/m3-lang.h:43: error: syntax error before > "procedures_have_extra_block" > ../../gdb/gdb/m3-lang.h:43: warning: type defaults to `int' in > declaration of `procedures_have_extra_block' > ../../gdb/gdb/m3-lang.h:43: warning: data definition has no type or > storage class > gmake[2]: *** [valops.o] Error 1 > gmake[2]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu/gdb' > gmake[1]: *** [all-gdb] Error 2 > gmake[1]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu' > gmake: *** [all] Error 2 From hosking at cs.purdue.edu Tue Aug 21 16:00:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:00:31 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> Message-ID: <6A045050-347B-4C7D-A185-1E1B240F940F@cs.purdue.edu> I'm the old one: SunOS arthur.cs.purdue.edu 5.8 Generic_117350-47 sun4u sparc SUNW,Sun- Fire-V250 On Aug 21, 2007, at 9:34 AM, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Without haveing investigated any of the issues above -- all this >> sounds to me like you are using a quite old Solaris system. I'd like >> to see the exact versions you and Tony use to build the software >> (uname -a). At least it might be a different worth to docuement. > > Not really. It's a V480 with Solaris 10: > > Kernel version: SunOS 5.10 Generic_118833-17 > > Alex. From hosking at cs.purdue.edu Tue Aug 21 16:52:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:52:18 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> Message-ID: <5F334086-0745-4C8D-9351-48C3B618271A@cs.purdue.edu> Yes, those are because your m3cc backend is configured to us GNU as, so it is just a matter of making sure your cm3.cfg uses the same assembler. In general, these problems are difficult to reconcile. I suspect we want SOLgnu to assume a full GNU toolchain and SOLsun to assume no GNU toolchain, but in many instances systems are configured as some hybrid of the two. For example, my gcc installation on Solaris is configured to use /usr/ccs/bin/as, and I don't have GNU ld installed either -- hence the definitions in my cm3.cfg. On Aug 21, 2007, at 10:21 AM, Alex Bochannek wrote: > Tony Hosking writes: > >>> o Ran into another problem with as and for some reason Tony's >>> cm3.cfg >>> used /usr/ccs/bin/as, which chokes on the GNU as directives. >>> Changed >>> cm3.cfg again. >> >> Which file chokes? Is it because your m3cc is configured to use >> GNU as? > > I get these kinds of errors: > > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: unknown opcode > ".subsection" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: statement syntax > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: unknown opcode > ".previous" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: statement syntax > > for RTHeapMap, RTTipe, RTTypeMap, RTExStack, and Poly when I run > do-cm3-core buildship. > >>> o do-cm3-core.sh completed and I did an install-cm3-compiler.sh >>> upgrade, >>> again as root since it's writing it into /usr/local/cm3 >>> >>> o Finally, did a do-cm3-std.sh buildship, which ran for quite a >>> while. >>> >>> o Ran into compile problems with Gdb (looked like a C99 issue, but I >>> didn't investigate it further. Just ran a cm3 in m3gdb again >>> and the >>> error is below.) >>> >>> o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh >>> buildship again. >>> >>> o The compile and install succeeded and I now have a nice new >>> cm3-d5.5.0. >>> >>> o Compiler some stuff in m3-games, just to make sure it really works >>> and >>> it looks like I am OK for now. I do see a number of core dumps >>> though >>> with some of apps, but I am not going to debug that at this point. >> >> What's core dumping? Is this from before my fixes to thread stopping >> yesterday? > > I just ran into problems with a couple of things out of m3-demo and > m3-games. Don't recall what it was (although Juno won't run right > now), > but I will do a CVS update and build a new system and report back if > something doesn't work. > > Alex. From dragisha at m3w.org Wed Aug 22 11:44:55 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:44:55 +0200 Subject: [M3devel] crashes everywhere Message-ID: <1187775896.31487.97.camel@faramir.m3w.org> *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 2316 *** m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: (m3gdb) bt #0 0x00d54402 in ?? () #1 0x430c7ba0 in raise () from /lib/libc.so.6 #2 0x430c94b1 in abort () from /lib/libc.so.6 #3 0x00eaf2ff in Crash () at RTOS.m3:20 #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 #7 0x00e9f212 in Crash (a= ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion `compiler_kind != ck_pm3' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From dragisha at m3w.org Wed Aug 22 11:58:44 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:58:44 +0200 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <1187776724.31487.103.camel@faramir.m3w.org> Another program, similar code... bt before I do set lang (still no idea why' problem there): #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol table. ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in symbol table. ) at RTCollector.m3:2316 #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol table. ) at Panda.m3:353 Line 353 is: AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); > INC(d.pdf.nextFontNumber); (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); *) AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not declared it "UNTRACED REF", and it is ref to C structure... I see these RTCollector bugs are happening from time to time, so I am posting this because I hope it can help other people identify it before they hit list (as I did:). m3gdb nastyness remains... On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From rodney.bates at wichita.edu Wed Aug 22 16:27:07 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 22 Aug 2007 09:27:07 -0500 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <46CC47BB.1050502@wichita.edu> I was unable to reproduce this m3gdb problem, but I looked at ways this could happen. In your case, m3gdb is getting conflicting information about whether it is debugging a program compiled by pm3 or cm3. As a workaround, since we know (don't we?) that it is actually cm3, and that agrees with what m3gdb thinks at the time of the assertion failure, it is probably safe in this case to ignore the message and proceed. You might even try the bt command again immediately. This error should self-heal at this point. It would be helpful to me if you sent me the output of these commands: objdump -G | grep MM__m3main objdump -G | grep ObjectTypecell Substitute the appropriate paths for your linked executable and wherever it finds libm3core. Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- ------------------------------------------------------------- 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 Wed Aug 22 17:31:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:31:08 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> I can't speak for m3gdb, but something seems seriously wrong with your installation. What program is causing this crash? Please also tell me the version number of ThreadPThread.m3. The most recent version is 1.48 of 2007-08-20. On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:47:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:47:14 -0400 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187776724.31487.103.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <1187776724.31487.103.camel@faramir.m3w.org> Message-ID: On Aug 22, 2007, at 5:58 AM, Dragi?a Duri? wrote: > Another program, similar code... bt before I do set lang (still no > idea > why' problem there): > > #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol > table. > ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in > symbol table. > ) at RTCollector.m3:2316 > #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol > table. > ) at Panda.m3:353 > > Line 353 is: > > AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); > AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); > fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); >> INC(d.pdf.nextFontNumber); > (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); > *) > AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); > > d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not > declared > it "UNTRACED REF", and it is ref to C structure... What is the type of d, d.pdf, and d.pdf.nextFontNumber? Are you saying d.pdf is REF? Yet you are storing an UNTRACED REF in it? The garbage collector will definitely become confused in that situation. Try using gdb instead of m3gdb so I can see the value of the parameter 'ref' passed to CheckStoreTraced from CreateFont. > > I see these RTCollector bugs are happening from time to time, so I am > posting this because I hope it can help other people identify it > before > they hit list (as I did:). > > m3gdb nastyness remains... > > On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 2316 >> *** >> >> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >> >> (m3gdb) bt >> #0 0x00d54402 in ?? () >> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >> #2 0x430c94b1 in abort () from /lib/libc.so.6 >> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >> msgA=16_00ed8ee8, >> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >> #7 0x00e9f212 in Crash (a= >> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >> `compiler_kind != ck_pm3' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> >> I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:51:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:51:28 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187797188.31487.113.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> <1187797188.31487.113.camel@faramir.m3w.org> Message-ID: <86C11DDE-5087-414B-9256-B7727041B020@cs.purdue.edu> On Aug 22, 2007, at 11:39 AM, Dragi?a Duri? wrote: > It is not... It was a bug I've explained in my replly to message you > replied to... Are you saying that fixing the bug made the crash go away? > My code triggers it, but I suppose there is problem with > CheckStoreTraced tracing through REF to C structure... Compiler did > not > complain, ot it did not generate correct info about "untracedness" of > "REF to C structure"... I've fixed my code, but I do not think this > (my > message you replied show it) is correct way for CM3 to react to bug in > code logic. I agree that it would be nice for cm3 to give a warning or error when using REF to C structs, but I need to know how you declared the type to understand what can be checked statically. The alternative is to have CheckStoreTraced complain if it is passed a ref that is not a true heap referent. Can you tell me how you declared things originally? Was it declared that way in UNSAFE code? > dd > > On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: >> I can't speak for m3gdb, but something seems seriously wrong with >> your installation. What program is causing this crash? Please also >> tell me the version number of ThreadPThread.m3. The most recent >> version is 1.48 of 2007-08-20. >> >> On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: >> >>> *** >>> *** runtime error: >>> *** An array subscript was out of range. >>> *** file "../src/runtime/common/RTCollector.m3", line 2316 >>> *** >>> >>> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >>> >>> (m3gdb) bt >>> #0 0x00d54402 in ?? () >>> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >>> #2 0x430c94b1 in abort () from /lib/libc.so.6 >>> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >>> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >>> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >>> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >>> msgA=16_00ed8ee8, >>> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >>> #7 0x00e9f212 in Crash (a= >>> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >>> `compiler_kind != ck_pm3' failed. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> >>> I am using cvshead cm3, as of few days ago. >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 18:01:05 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 12:01:05 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187797188.31487.113.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> <1187797188.31487.113.camel@faramir.m3w.org> Message-ID: On Aug 22, 2007, at 11:39 AM, Dragi?a Duri? wrote: > It is not... It was a bug I've explained in my replly to message you > replied to... > > My code triggers it, but I suppose there is problem with > CheckStoreTraced tracing through REF to C structure... Compiler did > not > complain, ot it did not generate correct info about "untracedness" of > "REF to C structure"... I've fixed my code, but I do not think this > (my > message you replied show it) is correct way for CM3 to react to bug in > code logic. On reflection, it seems that the only way you could create a "REF" to a C structure is in UNSAFE code. In which case, you are the one responsible for the bug, rather than the compiler needing to warn you. Programmers of UNSAFE code need to be very careful when constructing REFs that are not obtained via NEW (I would argue that LOOPHOLE should almost never be used to construct a REF, except when absolutely necessary). Perhaps an appropriate warning would be for such loopholing. Then again programmers of UNSAFE code are assumed to know what they are doing. Of course, in safe code the only way to get a REF is using NEW, so there should be no problems there. > > dd > > On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: >> I can't speak for m3gdb, but something seems seriously wrong with >> your installation. What program is causing this crash? Please also >> tell me the version number of ThreadPThread.m3. The most recent >> version is 1.48 of 2007-08-20. >> >> On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: >> >>> *** >>> *** runtime error: >>> *** An array subscript was out of range. >>> *** file "../src/runtime/common/RTCollector.m3", line 2316 >>> *** >>> >>> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >>> >>> (m3gdb) bt >>> #0 0x00d54402 in ?? () >>> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >>> #2 0x430c94b1 in abort () from /lib/libc.so.6 >>> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >>> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >>> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >>> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >>> msgA=16_00ed8ee8, >>> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >>> #7 0x00e9f212 in Crash (a= >>> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >>> `compiler_kind != ck_pm3' failed. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> >>> I am using cvshead cm3, as of few days ago. >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From rodney.bates at wichita.edu Wed Aug 22 18:28:46 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 22 Aug 2007 11:28:46 -0500 Subject: [M3devel] A warning on dtoa.h Message-ID: <46CC643E.8000108@wichita.edu> I have located a case where dtoa.h (which is in libm3core) gives a wrong result when compiled by gcc 3.4.3 -O2 but works correctly with -O0. When compiled by gcc 4.1.1, this case works correctly with either optimization level. Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some "undefined" code remains to be seen. In either case, beware. It caused pm3 to miscompile the REAL constant 2.0, used in Table.mg, which made an instantiation of Table get a false runtime range error. It took days to track down. I had another instance of a bad real constant being compiled from a long time ago, that I never diagnosed. cm3 uses a virtually identical dtoa.h, and nothing in the call chain leading up to the instance where I found the problem is materially changed from pm3 to cm3, so probably cm3 is affected in the same way. -- ------------------------------------------------------------- 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 Wed Aug 22 19:34:00 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 13:34:00 -0400 Subject: [M3devel] A warning on dtoa.h In-Reply-To: <46CC643E.8000108@wichita.edu> References: <46CC643E.8000108@wichita.edu> Message-ID: Yes, I've been burned by this in the past too. For that reason, all my cm3.cfg files use -O in compile_c instead of -O3. I note that there is an updated dtoa, which perhaps we should be using instead, though I don't know if gcc optimizations still cause issues with it. I seem to recall it was something to do with aliasing, which gcc generates appropriate warnings for. I note that the newer dtoa requires some locking for preemptively- scheduled threads (as our later PTHREAD systems do), so perhaps some work is in order here. Here is the newer dtoa: -------------- next part -------------- A non-text attachment was scrubbed... Name: dtoa.c Type: application/octet-stream Size: 67983 bytes Desc: not available URL: -------------- next part -------------- On Aug 22, 2007, at 12:28 PM, Rodney M. Bates wrote: > I have located a case where dtoa.h (which is in libm3core) gives a > wrong result when compiled by gcc 3.4.3 -O2 but works correctly > with -O0. When compiled by gcc 4.1.1, this case works correctly > with either optimization level. > > Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some > "undefined" code remains to be seen. > > In either case, beware. It caused pm3 to miscompile the REAL constant > 2.0, used in Table.mg, which made an instantiation of Table get a > false > runtime range error. It took days to track down. I had another > instance of a bad real constant being compiled from a long time ago, > that I never diagnosed. > > cm3 uses a virtually identical dtoa.h, and nothing in the call chain > leading up to the instance where I found the problem is materially > changed from pm3 to cm3, so probably cm3 is affected in the same > way. > -- > ------------------------------------------------------------- > 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 Wed Aug 22 19:52:41 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 13:52:41 -0400 Subject: [M3devel] dtoa Message-ID: <12EDDFD3-D0D0-4003-AD66-C44B23809132@cs.purdue.edu> Also, note that since dtoa.h only implements strtod this may be the primary limitation on proper implementation of EXTENDED floating point (i.e., C long double). Currently, LONGREAL (C double) and EXTENDED are treated the same in CM3. Perhaps we should move to use of native strtold instead of the m3-strtod implemented in dtoa.h. From hosking at cs.purdue.edu Thu Aug 23 05:46:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 23:46:19 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: Message-ID: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> These will need more precise diagnosis. On Aug 22, 2007, at 11:28 PM, Alex Bochannek wrote: > I am building CVSup with the new CM3 and after applying the usual > patches plus the gettimeofday tz type patch, CVSup builds just fine on > Solaris 10. For testing purposes I am trying to get the cm3 repository > and am running into odd problems. > > o If I run the cvsup with the GUI, it shows up, I push the green arrow > and it immediately see "Cannot connect .... Error 0". I see a TCP > connection attempt, but it is being reset. > > o If I run it with -g -L 2, I get either: What do these flags do? The rest of your errors indicate something is terribly wrong with the threading subsystem. > > *** > *** runtime error: > *** Thread client error: Acquire of mutex already locked by self > *** file "ThreadPThread.m3", line 112 > *** This is a sanity check to make sure mutexes are not double-acquired. > > which is not reproducible but happens every once in a while, or: > > Updater failed: Cannot create directories leading to "/opt/cm3/ > cm3-cvs/sup/cm3/#cvs.cvsup-23065.0": Resource temporarily unavailable > > for every single subdirectory it needs to create. > > o If I create the subdirectories manually, the copies will start and I > eventually run into errors like the following ones for different > files: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/runtime/common/RTType.m3", line 71 > *** One question: did you completely rebuild all the libraries? > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** Something very broken. Perhaps LockHeap is not functioning properly? > > or > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/FileStatus.m3", line 505 > *** Where is this module? > > or > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x4619c8 = MyGetWideChars + 0x74 in ../src/text/ > TextSub.m3 > *** > > None of this happens with the EZM3 CVSup. The reason I am trying to do > all this, by the way is because I am looking at enhancing CVSup a > little > bit to get more information about repository structure and to also > resolve some issues I have seen with checksum errors. Learning > about the > CM3 environment in the process is interesting as well, of course. Hmm... How do we proceed in debugging this? > > Alex. > > P.S.: Not sure if this message makes it to m3devel. I don't think it > will since I read it through the Web site. From jdp at polstra.com Thu Aug 23 06:04:44 2007 From: jdp at polstra.com (John Polstra) Date: Wed, 22 Aug 2007 21:04:44 -0700 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> Message-ID: <46CD075C.7050001@polstra.com> Alex Bochannek wrote: > Tony Hosking writes: >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> This is a sanity check to make sure mutexes are not double-acquired. > > I suspect a race condition somewhere since it's not easily reproducible. Not many race conditions are possible in CVSup. It's multi-threaded, but the threads basically don't interact with each other and don't require locking against each other. It's more like a pipeline, with one thread feeding another thread, but virtually no interaction between threads otherwise. > >> One question: did you completely rebuild all the libraries? > > As far as I know. I'd be happy to do it again though. > >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> Where is this module? > > CVSup code in the suplib library. The relevant procedure starts out like > this: > > PROCEDURE WrPut(ww: WrWriter; fs: T) > RAISES {Error, Thread.Alerted, Wr.Failure} = > VAR > pcType: PathComp.Type; > pcName: TEXT; > dirUpAttr: FileAttr.T; > BEGIN > IF ww.cannotWrite THEN (* Don't even try. *) > RETURN; > END; > IF ww.current # NIL THEN (* Don't ever write the records out of order. *) > <* ASSERT Compare(ww.current, fs) < 0 *> > END; > ww.current := fs; Something's *really* screwed up. I've never in 10 years seen this assertion fail. John From dragisha at m3w.org Wed Aug 22 17:39:47 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 17:39:47 +0200 Subject: [M3devel] crashes everywhere In-Reply-To: <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> Message-ID: <1187797188.31487.113.camel@faramir.m3w.org> It is not... It was a bug I've explained in my replly to message you replied to... My code triggers it, but I suppose there is problem with CheckStoreTraced tracing through REF to C structure... Compiler did not complain, ot it did not generate correct info about "untracedness" of "REF to C structure"... I've fixed my code, but I do not think this (my message you replied show it) is correct way for CM3 to react to bug in code logic. dd On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: > I can't speak for m3gdb, but something seems seriously wrong with > your installation. What program is causing this crash? Please also > tell me the version number of ThreadPThread.m3. The most recent > version is 1.48 of 2007-08-20. > > On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: > > > *** > > *** runtime error: > > *** An array subscript was out of range. > > *** file "../src/runtime/common/RTCollector.m3", line 2316 > > *** > > > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > > > (m3gdb) bt > > #0 0x00d54402 in ?? () > > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > > #2 0x430c94b1 in abort () from /lib/libc.so.6 > > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > > #7 0x00e9f212 in Crash (a= > > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > > `compiler_kind != ck_pm3' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > > > I am using cvshead cm3, as of few days ago. > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Aug 23 16:27:15 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 10:27:15 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> Message-ID: You don't need m3gdb to get back traces. gdb works fine for that. On Aug 22, 2007, at 11:53 PM, Alex Bochannek wrote: > Tony Hosking writes: > >>> o If I run it with -g -L 2, I get either: >> >> What do these flags do? > > Sorry, those are CVSup client flags. No GUI (-g) and verbosity level 2 > (-L 2). > >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by >>> self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> >> This is a sanity check to make sure mutexes are not double-acquired. > > I suspect a race condition somewhere since it's not easily > reproducible. > >> One question: did you completely rebuild all the libraries? > > As far as I know. I'd be happy to do it again though. > >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> >> Where is this module? > > CVSup code in the suplib library. The relevant procedure starts out > like > this: > > PROCEDURE WrPut(ww: WrWriter; fs: T) > RAISES {Error, Thread.Alerted, Wr.Failure} = > VAR > pcType: PathComp.Type; > pcName: TEXT; > dirUpAttr: FileAttr.T; > BEGIN > IF ww.cannotWrite THEN (* Don't even try. *) > RETURN; > END; > IF ww.current # NIL THEN (* Don't ever write the records out > of order. *) > <* ASSERT Compare(ww.current, fs) < 0 *> > END; > ww.current := fs; > >> Hmm... How do we proceed in debugging this? > > If I had been able to build the m3gdb, maybe I could get backtraces > from > the core files? > > Alex. From hosking at cs.purdue.edu Thu Aug 23 16:29:39 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 10:29:39 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: <1187849384.31487.139.camel@faramir.m3w.org> References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> Message-ID: Sounds like I should do a build on my Solaris box and see if things work for me. On Aug 23, 2007, at 2:09 AM, Dragi?a Duri? wrote: > These'll need more errorprone instructions on install/upgrade, or more > reading of same :). This is kind of problems I've had when > something is > not built in correct order/not updated fully. > > I've build suplib & client moments ago and got this: > > faramir:dragisha/pts/15: src/cvsup-snap-16.1h/client% ./LINUXLIBC6/ > cvsup > -g ~/cvsupfile.cm3 > Connected to birch.elegosoft.com > Updating collection cm3/cvs > Updating collection cvsroot/cvs > Append to CVSROOT/history > Finished successfully > > I am not using suptcp, it's part of "patching" done for some earlier > cm3... Got this patch from this list, most probably. > > On Wed, 2007-08-22 at 23:46 -0400, Tony Hosking wrote: >> These will need more precise diagnosis. >> >> On Aug 22, 2007, at 11:28 PM, Alex Bochannek wrote: >> >>> I am building CVSup with the new CM3 and after applying the usual >>> patches plus the gettimeofday tz type patch, CVSup builds just >>> fine on >>> Solaris 10. For testing purposes I am trying to get the cm3 >>> repository >>> and am running into odd problems. >>> >>> o If I run the cvsup with the GUI, it shows up, I push the green >>> arrow >>> and it immediately see "Cannot connect .... Error 0". I see a TCP >>> connection attempt, but it is being reset. >>> >>> o If I run it with -g -L 2, I get either: >> >> What do these flags do? >> >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by >>> self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> >> This is a sanity check to make sure mutexes are not double-acquired. >> >>> >>> which is not reproducible but happens every once in a while, or: >>> >>> Updater failed: Cannot create directories leading to "/opt/cm3/ >>> cm3-cvs/sup/cm3/#cvs.cvsup-23065.0": Resource temporarily >>> unavailable >>> >>> for every single subdirectory it needs to create. >>> >>> o If I create the subdirectories manually, the copies will start >>> and I >>> eventually run into errors like the following ones for different >>> files: >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../src/runtime/common/RTType.m3", line 71 >>> *** >> >> One question: did you completely rebuild all the libraries? >> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 688 >>> *** >>> >>> >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 688 >>> *** >> >> Something very broken. Perhaps LockHeap is not functioning properly? >> >>> >>> or >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> >> Where is this module? >> >>> >>> or >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference >>> NIL >>> *** pc = 0x4619c8 = MyGetWideChars + 0x74 in ../src/text/ >>> TextSub.m3 >>> *** >>> >>> None of this happens with the EZM3 CVSup. The reason I am trying >>> to do >>> all this, by the way is because I am looking at enhancing CVSup a >>> little >>> bit to get more information about repository structure and to also >>> resolve some issues I have seen with checksum errors. Learning >>> about the >>> CM3 environment in the process is interesting as well, of course. >> >> Hmm... How do we proceed in debugging this? >> >>> >>> Alex. >>> >>> P.S.: Not sure if this message makes it to m3devel. I don't think it >>> will since I read it through the Web site. >> > -- > Dragi?a Duri? From rodney.bates at wichita.edu Fri Aug 24 02:21:32 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 23 Aug 2007 19:21:32 -0500 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: <46CE248C.6070702@wichita.edu> I just noticed that the failing code here looks a lot like the failure I traced to the dtoh problem. Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; > >>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > -- ------------------------------------------------------------- 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 Fri Aug 24 04:03:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 22:03:56 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <46CE248C.6070702@wichita.edu> References: <1187611284.31487.42.camel@faramir.m3w.org> <46CE248C.6070702@wichita.edu> Message-ID: <69DE3922-2AA7-4446-8815-1D0BFD3C2D18@cs.purdue.edu> I tracked this one down to a problem with building m3cc on x86_64. It turns out (for reasons yet to be determined) that floating point constants get built wrong when m3cc is configured with CC="gcc -m32" that the problem goes away. This problem is internal to the gcc- based backend, so dtoa is not involved. On Aug 23, 2007, at 8:21 PM, Rodney M. Bates wrote: > I just noticed that the failing code here looks a lot like the failure > I traced to the dtoh problem. > > Dragi?a Duri? wrote: >> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >> (skipping >> m3gdb, which I've reported earlier would not compile for me) I am >> getting this error when I try to rn one of programs that worked >> flawlessy few checkouts ago. >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "../src/uid/Common/TimeStamp.m3", line 63 >> *** >> This is corresponding code: >> now := Time.Now() - epoch; >> >>> time := TRUNC(now); >> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >> LONGREAL), 8)); >> I've identified few other problems, but I suppose ther are all >> variations... >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Aug 26 14:22:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:22:17 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: still no int64/longint support, but there's another build in ~jkrell on m3.elegosoft.comanyone want to try it?Jay at jay-win8 ~$ find ../cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2./cm3-min-WIN32-NT386-d5.5.0.tar.bz2Jay at jay-win8 ~$ pwd/home/Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 26 14:25:26 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:25:26 +0000 Subject: [M3devel] webscape crash Message-ID: I can't seem to get the hang of any of the modula-3 gui apps. They all look a bit clunky and act wierd or don't do much. Probably QT or GTk or wxWindows "bindings" are in order.. (QT is my pick..)mentor doesn't do much.deckscape and webscape don't much.I was able to crash webscape pretty quickly.0:014> .lasteventLast event: 4c4.5c0: Access violation - code c0000005 (first chance) debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7)0:014> u .m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]:005610b4 8b5e00 mov ebx,dword ptr [esi]005610b7 8b5300 mov edx,dword ptr [ebx]005610ba 8955e0 mov dword ptr [ebp-20h],edx005610bd 8d7de8 lea edi,[ebp-18h]005610c0 57 push edi005610c1 56 push esi005610c2 83fa00 cmp edx,0005610c5 750a jne m3core!RTHooks__Concat+0x8d (005610d1)0:014> r esiesi=000000000:014> kChildEBP RetAddr0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ 173]0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97]0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41]0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271]0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 [WebVBT.m3 @ 182]0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225]0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124]0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 [ThreadWin32.m3 @ 583]0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a [ThreadWin32.m3 @ 548]WARNING: Stack unwind information not available. Following frames may be wrong.0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b40:014> |. 0 id: 4c4 create name: WebScape.exe0:014> _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 26 17:38:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Aug 2007 11:38:52 -0400 Subject: [M3devel] another m3 build for win32.. In-Reply-To: References: Message-ID: PS There is LONGINT support for NT386, but it is just 32-bit, not 64-bit, so no improvement over INTEGER. On Aug 26, 2007, at 8:22 AM, j k wrote: > still no int64/longint support, but there's another build in > ~jkrell on m3.elegosoft.com > > anyone want to try it? > > Jay at jay-win8 ~ > $ find . > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Jay at jay-win8 ~ > $ pwd > /home/Jay > > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From hosking at cs.purdue.edu Sun Aug 26 17:40:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Aug 2007 11:40:08 -0400 Subject: [M3devel] webscape crash In-Reply-To: References: Message-ID: <8D17B1B0-54D5-4AAF-ABCE-0DBEB510CD38@cs.purdue.edu> Yikes, that seems like a problem since this is supposed to be builtin string concatenation. On Aug 26, 2007, at 8:25 AM, j k wrote: > I can't seem to get the hang of any of the modula-3 gui apps. They > all look a bit clunky and act wierd or don't do much. Probably QT > or GTk or wxWindows "bindings" are in order.. (QT is my pick..) > mentor doesn't do much. > deckscape and webscape don't much. > I was able to crash webscape pretty quickly. > > 0:014> .lastevent > Last event: 4c4.5c0: Access violation - code c0000005 (first chance) > debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7) > 0:014> u . > m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]: > 005610b4 8b5e00 mov ebx,dword ptr [esi] > 005610b7 8b5300 mov edx,dword ptr [ebx] > 005610ba 8955e0 mov dword ptr [ebp-20h],edx > 005610bd 8d7de8 lea edi,[ebp-18h] > 005610c0 57 push edi > 005610c1 56 push esi > 005610c2 83fa00 cmp edx,0 > 005610c5 750a jne m3core!RTHooks__Concat+0x8d > (005610d1) > 0:014> r esi > esi=00000000 > 0:014> k > ChildEBP RetAddr > 0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27] > 0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ > 173] > 0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97] > 0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41] > 0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271] > 0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 > [WebVBT.m3 @ 182] > 0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225] > 0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124] > 0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 > [ThreadWin32.m3 @ 583] > 0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a > [ThreadWin32.m3 @ 548] > WARNING: Stack unwind information not available. Following frames > may be wrong. > 0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b4 > 0:014> | > . 0 id: 4c4 create name: WebScape.exe > 0:014> > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Mon Aug 27 03:18:43 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 01:18:43 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: details.. :) > From: hosking at cs.purdue.edu> Date: Sun, 26 Aug 2007 11:38:52 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > PS There is LONGINT support for NT386, but it is just 32-bit, not > 64-bit, so no improvement over INTEGER.> > > On Aug 26, 2007, at 8:22 AM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 27 03:55:36 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 26 Aug 2007 21:55:36 -0400 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: <46D1F6E3.1E75.00D7.1@scires.com> Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 07:30:05 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 05:30:05 +0000 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: Randy, This is good to hear. Btw, there is no guaranteed of short names being available. You can do: fsutil behavior set disable8dot3 1 Btw, short names can be longer than long names, but true they can't have spaces. What a hack..C:\>mkdir \1.1.1 C:\>dir /x /ad 1*08/26/2007 10:10 PM 112E5D~1.1 1.1.1 The notion of passing a run of strings on a flat command line string with spaces between them when the items can have spaces in the first place is obviously broken. You can play with quoting, but then it's a never ending cycle of guessing how many times the quotes are going to be processed and with which rules. The right way to pass an array of strings around is to actually pass an array of strings.. Oh well.. Still I guess changing cm3 to try to use them in some cases might be a reasonable idea. I guess nobody cares on Unix about the spaces? I don't have any spaces, like in running the compiler or linker because 1) I install to \msdev\, none of the \program files places 2) by depending on %path% search. The current source does build with the latest released binaries, if you build in the right order and such. cm3\scripts\win\make-dist.cmd works. Somewhat precisely, from memory, you can do like: rmdir /q/s \cm3 extract latest distribution to \cm3 -- the system.tgz file. You don't need to run the cminstall.exe. cvs checkout to \dev2\cm3 copy \dev2\cm3\m3-sys\cminstall\src\config\nt386 \cm3\bin\cm3.cfg You don't need to edit the file at all, you just need %PATH%, %INCLUDE%, and %LIB% set. There are tradeoffs either way. This lets you changed Visual C++ toolsets by starting a new cmd and running another vcvars32.bat, instead of using a different cm3 configuration file. set some environment variables, mainly put cm3.exe in %PATH% and run the vcvars32.bat or such that Visual C++ includes, or start the Visual C++ command prompt from the start menu. cd \dev2\cm3\scripts\win .\make-dist This will give you something like (it will tell you exactly) %temp%\cm3\\cm3-5.5.0-min.tar.bz2 rmdir /q/s \cm3 extract the cm3-5.5.0-min.tar.bz2 to \cm3 If folks wants a .zip or a self expanding .zip, that is easily done. Tar.bz2 is reliably significantly smaller. Again cd to \dev2\cm3\scripts\win and run make-dist, or better yet do-cm3-std realclean and do-cm3-std buildship. As to the actual stability, I can't say. It is enough to build itself and then use that to build more stuff. I'm afraid I haven't looked at the cm3 gui stuff much. It seems very clunky. I guess we'll have to debug or compare the old and new source. I do remember seeing some questionable commits, like claims that Windows behavior had changed or that the author didn't know what was going but that some strange thing seemed to help. Windows really has a huge compatibility burden and the comments I thought were suspicous. Something around processing keystrokes and something around the environment variables passed to main. 4.1 is the old latest commercial release?I have that. I doubt it will build the current source. There is a file describing how to bootstrap from the older 3.6 release I think. I have not tried that. I believe WIDETEXT and WIDECHAR and such cause problems. Perhaps the compiler should use a strict subset of Modula-3 buildable with particular releases? The problem is probably a blurry line between compiler and runtime and the need to actually implement new features causing some circular dependency?? That's excellent about getting more of the source released. I had no idea what that would take. > same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP) Do folks still care about Win9x? 95? VC 8.0 binaries do not work on 95 for small reasons like use of IsDebuggerPresent and InterlockedCompareExchange. These are easily worked around if folks desire, or use an older toolset. (I didn't find Reactor all that impressive but ok. It is nice to hyperlink all the source, but it was hardly an IDE.) - Jay Date: Sun, 26 Aug 2007 21:55:36 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] cm3 on Windows, plus "Reactor" sources Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSPSenior Systems Engineer, Communications, Networks, & Electronics Division (CNE)Corporate & Atlanta Information Systems Security Manager (ISSM)Scientific Research Corporation2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Aug 27 07:39:14 2007 From: darko at darko.org (Darko) Date: Mon, 27 Aug 2007 07:39:14 +0200 Subject: [M3devel] another m3 build for win32.. In-Reply-To: References: Message-ID: I'm interested, but what windows tools does it require? On 26/08/2007, at 2:22 PM, j k wrote: > still no int64/longint support, but there's another build in > ~jkrell on m3.elegosoft.com > > anyone want to try it? > > Jay at jay-win8 ~ > $ find . > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Jay at jay-win8 ~ > $ pwd > /home/Jay > > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Mon Aug 27 09:04:53 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:04:53 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: simple answer and sufficient: "free" Visual C++ 8.0 compiler and linker search the web for "visual C++ express edition" => http://msdn2.microsoft.com/en-us/express/aa700735.aspx You don't need the IDE, so I don't /think/ you have to "register". Once you install it, the shortcut on the start menu to a cmd with some environment variables set is useful. I wrap it up in my own "environment" .cmd files, like \env\ms\vc80.bat and \env\cm3.vc80.bat (which uses \env\cm3.bat) TBD making these available to folks. They aren't quite generic but they are somewhat. The redist. Search the web for "Visual C++ redist" or "vcredist_X86.exe" => http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en or search for "vcredist_X86.exe sp1" or => http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en probably a Windows Platform SDK, not sure (and certainly not with the non-free Visual C++) search the web for "Windows Platform SDK" => http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en or => http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en I'm not even sure this is needed. Pretty much version will do, probably even the non-Microsoft ones such as ship with Mingwin/cygwin/openwatcom. The dependencies are fairly light, the Modula-3 system tries to be fairly self contained. more generally: I did some testing and applied some fixes with a range of toolsets: Visual C++ 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0. They should all work. You can get any of them from www.ebay.com. 7.1 used to be a free download. There is a beta out of 9.0 already. The binaries where built with 8.0 and so don't work on Windows 95 and require the redist. If folks really don't like that, there are alternatives, such as using libcmt.lib or using older toolsets, but using 8.0 and the redist and dropping Windows 95 seems very reasonable. I am /somewhat/ interested in adding support for other toolsets, like maybe www.openwatcom.com.And/or heck finish the work in CM3 on cutting the linker dependency, either write a linker in Modula-3 or load up the .objs at runtime. Oh, and tar and bzip2. I use the Cygwin versions. tar accepts the "j" flag to decompress bzip2. so like: rmdir /q/s \cm3 mkdir \cm3 cd \cm3 tar tjvz foo.tar.bz2 add \cm3\bin to %PATH% .tar.gz, .zip, self extracting .zip are all trivial to provide if tar/bzip2 is really an onerous dependency. .tar.bz2 is consistently and significantly smaller. The "support", like all of 2 lines of code, is in cm3\scripts\win\make-dist.cmd. - Jay > From: darko at darko.org> Date: Mon, 27 Aug 2007 07:39:14 +0200> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > I'm interested, but what windows tools does it require?> > > On 26/08/2007, at 2:22 PM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:19:52 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:19:52 +0000 Subject: [M3devel] platform names? Message-ID: Anyone want to propose platform names? Adopt a "system" where "OS", toolset, runtime, processor, and/or pointer size are clear, or just keep using short CAPS informal non-systematic names? NT386Wat? NT386WAT?? <== seems most likely given the current short informal CAPS non-systematic pattern NT386WATCOM? NT386Watcom? NTx86Watcom? Win32-x86-watcom? win-x86-openwatom1.7? NTAMD64? <== seems most likely given the current short informal CAPS non-systematic pattern NTIA64? win64-amd64-msc? (msc -- toolset and runtim, vs. say GNU or Watcom) win-amd64-msc? (drop "64" in favor of architecture, leaving win-x86 ambiguous though -- win-286, win-386?) win16? win64? Or just win + architecture or nt + architecture? Way too ambiguous. There is IA64 and there was Alpha64. Consider there is also Windows CE. win-mips? win-powerpc? wince-powerpc?winnt-powerpc? msnt-powerpc? msce-powerpc? msce-arm? (msc -- "Microsoft C" -- toolset and runtime) I am not suggesting developering support for any of these mind you. Which reminds me -- most of the architectures are dead. Should they be deleted? Resusicated? Resusicated if gcc supports them? Do nothing? I know I know, 64 bit integer support on NT386 is the most important thing to do right now. - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Aug 7 23:49:23 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 07 Aug 2007 21:49:23 -0000 Subject: [M3devel] LONGINT Message-ID: Shortly I will be checking in compiler and run-time updates that enable the LONGINT type: 32 <= BITSIZE(INTEGER) <= BITSIZE(LONGINT) <= 64 Here are the changes to the language spec, in the form of context diffs to the updated reference manual, which is available at http:// www.cs.purdue.edu/~hosking/m3/reference/index.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diffs Type: application/octet-stream Size: 15769 bytes Desc: not available URL: -------------- next part -------------- I have gone for the minimalist approach to adding LONGINT to the language. In brief, LONGINT is a distinct ordinal type from INTEGER. Conversions can be performed using ORD and VAL. For LONGINT 'n', ORD(n) converts n to an INTEGER. For INTEGER 'n', VAL (n, LONGINT) converts n to a LONGINT. Implicitly, this means all enumerations have an underlying INTEGER representation. LONGINT subranges work as expected. Open arrays are indexed by INTEGER values. Fixed arrays can have an index type whose base type is LONGINT. The rest of the changes to the language spec flow from these fundamentals. From rcoleburn at scires.com Thu Aug 9 01:28:05 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 08 Aug 2007 23:28:05 -0000 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <46BA192B.1E75.00D7.1@scires.com> Rodney: I believe that on Windows (Win32) the implementation uses native OS threads. At least that is how it worked for cm v4.1. Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:07:37 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:07:37 -0000 Subject: [M3devel] compiling the C code as C++? Message-ID: I was going through diffs I had around. One set is mostly putting #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif around all the C code, and a little something for the K&R code. The point was to compile all the C code as C++. I assume I had it working but I'll have to get back up to speed to verify that. Thoughts? - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:27:27 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:27:27 -0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? Message-ID: I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really? Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some. Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history". All you need is the following: signed and unsigned integer types that are exactly 8 bits in size signed and unsigned integer types that are exactly 16 bits in size signed and unsigned integer types that are exactly 32 bits in size signed and unsigned integer types that are exactly 64 bits in size signed and unsigned integer types that are exactly the size of a pointer 10 integer types total, named something like: INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit: int => INT => INT_PTR unsigned => UINT => UINT_PTR DWORD => DWORD_PTR convert to the upper case types if not there, and append "_PTR" The existing types size_t and ptrdiff_t did change size. If someone really needed 32 bit types there, you'd have to change your code. Windows has more than that for historical and stylistics reasons -- upper case types, lowercase types, types that "favor" being unsigned int or unsigned long. Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary. C 9x adds in "fast" and "small" types types that are the smallest type that is at least a certain size, I think types that are the fastest type that are at least a certain size, I think the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out beyond necessity. Yeah, obviously, they seem like maybe you might want them, but it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient to use on all forseeable processors, since tons of code uses them, and people should not will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are mostly stupid these days and they very often should be widened, but folks can do that "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used. Why has this been so hard in Modula-3? Is it that "Word" is widely used and has been pointer sized? Or that INTEGER has been widely used and sometimes assumed to be pointer sized? Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but weren't done right and there is some legacy we are stuck with?? Do "subrange" types make it all confusing? Or merely the assignment rules among the non subrange integer types? I have not paid particularly close attention; it just has always surprised me that it was difficult to work out what to do. I guess it is all moot now, the issues have been worked out and the feature is there. Good. I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly abstracted C names "short", "int", "long" are a useful abstraction. I think you really want the 10 base types I first listed. btw, even the types that are same size as a pointer are overused in C/C++. You don't need them for as much pointer arithmetic as people use. You can use "char*" for that. They are useful for array indices though, the result of wcslen, sizeof(), etc. File sizes should always be UINT64.. - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 17:18:34 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 15:18:34 -0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <3AAAC6BE-6742-4B5C-882F-980D1DA39D00@darko.org> The point of M3 is not be different than some other language, the point is for it to be safe, and, as a side effect, easy to use. Making a language safe is hard becuase you have to consider every possible usage and outcome becuase the language guarantees that it will not produce an "unchecked" error for the safe subset of the language, that is, it will do something random no matter how use use the language. So we have to consider all changes very carefully. On 11/08/2007, at 4:26 PM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 19:07:12 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:07:12 -0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: I can build the compiler, but, youch, can't build m3core\long.m3: "..\src\word\Long.m3", line 11: Unknown type of size other than dword in movOp The x86 back end needs work..I'll see if I can't just provide this stuff in C and avoid understanding the backend much.. - Jay> From: hosking at cs.purdue.edu> Date: Wed, 8 Aug 2007 08:39:34 -0400> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > Make sure to start with clean build directories and clean before > building with the bootstrapped compiler...> > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote:> > > Amended bootstrap instructions:> >> > Compiler and runtime extensions to support LONGINT type.> > > > Bootstrapping instructions: build and ship packages in the > > following order> > > > m3cc> > m3middle> > m3linker> > m3front> > m3quake> > cm3> > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> > > > Use this new compiler to build and ship the new system:> > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> > cd cm3/scripts> > ./do-cm3-std.sh realclean> > > ./do-cm3-std.sh buildship> > > > If this is successful then move the new compiler to BINDIR:> > > > mv $CM3 INSTALL_DIR/bin/cm3> >> > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: hosking at birch. 07/08/08 05:50:13> >>> >> Modified files:> >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html> >> for.html index.html m3.html m3index.html> >> numbers.html ordinal.html subtypes.html> >> typeops.html word-intf.html> >> cm3/m3-db/smalldb/src/: OSSupport.m3> >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3> >> SocketPosix.m3> >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3> >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c> >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3> >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3> >> cm3/m3-libs/m3core/src/thread/: m3makefile> >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3> >> Utypes.i3> >> m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/word/: m3makefile> >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> cm3/m3-sys/m3front/src/: m3makefile> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3> >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3> >> Dec.m3 First.m3 Floatt.m3> >> Floor.m3 Inc.m3 Last.m3> >> Max.m3 New.m3 Number.m3> >> Ord.m3 Round.m3 Subarray.m3> >> Trunc.m3 Val.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3> >> m3makefile> >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3> >> WordInsert.m3 WordModule.m3> >> WordNot.m3 WordOr.m3> >> WordRotate.m3 WordShift.m3> >> WordXor.m3> >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3> >> CastExpr.m3 CheckExpr.m3> >> CompareExpr.m3 DivExpr.m3> >> EqualExpr.m3 Expr.m3 ExprParse.m3> >> InExpr.m3 IntegerExpr.i3> >> IntegerExpr.m3 ModExpr.m3> >> MultiplyExpr.m3 NegateExpr.m3> >> ReelExpr.i3 ReelExpr.m3> >> SetExpr.m3 SubscriptExpr.m3> >> SubtractExpr.m3> >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3> >> Marker.m3 Scanner.m3 TipeDesc.i3> >> TipeDesc.m3 Token.i3 Token.m3> >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3> >> ForStmt.m3 TryFinStmt.m3> >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3> >> OpenArrayType.m3 SubrangeType.m3> >> Type.i3 Type.m3> >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3> >> Module.m3 Variable.m3> >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3> >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3> >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3> >> TWord.i3 TWord.m3 Target.i3 Target.m3> >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3> >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3> >> M3Lexer.m3 M3Type.i3 M3Type.m3> >> cm3/m3-tools/m3browser/src/: Main.m3> >> Added files:> >> cm3/doc/reference/: m3logo.gif> >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3> >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3> >> LongDivide.i3 LongDivide.m3> >> LongExtract.i3> >> LongExtract.m3 LongGE.i3> >> LongGE.m3 LongGT.i3> >> LongGT.m3 LongInsert.i3> >> LongInsert.m3 LongLE.i3> >> LongLE.m3 LongLT.i3> >> LongLT.m3 LongMinus.i3> >> LongMinus.m3 LongMod.i3> >> LongMod.m3 LongModule.i3> >> LongModule.m3 LongNot.i3> >> LongNot.m3 LongOr.i3> >> LongOr.m3 LongPlus.i3> >> LongPlus.m3 LongRotate.i3> >> LongRotate.m3 LongShift.i3> >> LongShift.m3 LongTimes.i3> >> LongTimes.m3 LongXor.i3> >> LongXor.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3> >>> >> Log message:> >> Compiler and runtime extensions to support LONGINT type.> >> > >> Bootstrapping instructions: build and ship packages in the > >> following order> >> > >> m3middle> >> m3linker> >> m3front> >> m3quake> >> cm3> >> > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> >> > >> Use this new compiler to build and ship the new system:> >> > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> >> cd cm3/scripts> >> ./do-cm3-std.sh buildship> >> > >> If this is successful then move the new compiler to BINDIR:> >> > >> mv $CM3 INSTALL_DIR/bin/cm3> >> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:53:11 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:53:11 -0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Ok, other than calling it "the x86 backend", I think I'm right. I wasn't sure if it was for all x86 platforms or just Windows.How about the "non gcc" backend? I think only Windows uses it and no other platform.I can get much further still having fixed BuildStandalone functionality in m3-sys\cminstall\src\config\NT386. I broke it a few months ago. I got as far as m3ui and something with RTHeapDep, I think the problem there is the interface got deleted between the last binary distribution and now. I'll dig a bit more.After fixing BuildStandalone, tried again with the inline Long.m3 and got the same errors so I put back my C implementation -- I am NOT sure it is right, either in calling convention or in implementing the shift/rotate/extract/insert stuff correctly.Now cm3 -ship works on m3core.dll as well but that's a different point. - JayFrom: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Sat, 11 Aug 2007 17:55:06 +0000Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> New home for Mom, no cleanup required. All starts here. _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:55:40 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:55:40 -0000 Subject: [M3devel] missing commits Message-ID: fyi, I'm not seeing my commits, probably my fault with my screwy-for-months-now mail configuration. I do intend to fix it soon... - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 22:16:36 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 20:16:36 -0000 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> The last commit I got was beginning of April. I think there might be a wider problem. On 11/08/2007, at 8:54 PM, j k wrote: > fyi, I'm not seeing my commits, probably my fault with my screwy- > for-months-now mail configuration. I do intend to fix it soon... > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 07:24:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 05:24:17 -0000 Subject: [M3devel] missing commits Message-ID: I am getting Tony's .tex commits, but didn't see mine.I say this half to cover my butt -- I made some commits.If I'm not seeing them, others maybe aren't either.I added a C version of Long.m3 for Win32.Not sure it is right, in a few ways. How it uses the stack. If it shifts and all by the right amounts? (n or 64 - n?) It definitely lets the build progress further. Surely it isn't ideal -- the C code actually generates calls out to the C runtime even, under the covers, so what was meant to be inlined is a two deep call tree! (The compiler generates the calls.)I fixed cminstall/src/config/NT386 so BuildStandalone works.I fixed scripts/win/clearenv.cmd so the user can set CM3 as per Tony's bootstrap instructions.Maybe others, don't recall.Nothing large.I figure I'll remove a bunch of extra semicolons in some C code.Any thoughts on the #ifdef __cplusplus extern "C" in C code? - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 19:01:40 -0400> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > I know there was a problem with the mailing list and I ended up re- > subscribing using my CVS username from the elegosoft web-site. It > seems that commits via CVS accounts pipe to the mailing list, but you > need to be subscribed with that id.> > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > > The last commit I got was beginning of April. I think there might > > be a wider problem.> >> >> > On 11/08/2007, at 8:54 PM, j k wrote:> >> >> fyi, I'm not seeing my commits, probably my fault with my screwy- > >> for-months-now mail configuration. I do intend to fix it soon...> >>> >> - Jay> >>> >> Recharge--play some free games. Win cool prizes too! Play It!> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:20:20 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:20:20 -0000 Subject: [M3devel] missing commits Message-ID: Because it doesn't work currently. This was easier but I agree not ideal. - Jay> From: hosking at cs.purdue.edu> Date: Sun, 12 Aug 2007 04:16:22 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > Why do you need a C version of Long.m3 for Win32? These operations > are built into the front-end, making use of backend functionality.> > On Aug 12, 2007, at 1:24 AM, j k wrote:> > > I am getting Tony's .tex commits, but didn't see mine.> > I say this half to cover my butt -- I made some commits.> > If I'm not seeing them, others maybe aren't either.> >> > I added a C version of Long.m3 for Win32.> > Not sure it is right, in a few ways.> > How it uses the stack.> > If it shifts and all by the right amounts? (n or 64 - n?)> > It definitely lets the build progress further.> > Surely it isn't ideal -- the C code actually generates> > calls out to the C runtime even, under the covers, so what> > was meant to be inlined is a two deep call tree!> > (The compiler generates the calls.)> >> > I fixed cminstall/src/config/NT386 so BuildStandalone works.> >> > I fixed scripts/win/clearenv.cmd so the user> > can set CM3 as per Tony's bootstrap instructions.> >> > Maybe others, don't recall.> > Nothing large.> >> > I figure I'll remove a bunch of extra semicolons in some C code.> >> > Any thoughts on the #ifdef __cplusplus extern "C" in C code?> >> > - Jay> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 11 Aug 2007 19:01:40 -0400> > > To: darko at darko.org> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] missing commits> > >> > > I know there was a problem with the mailing list and I ended up re-> > > subscribing using my CVS username from the elegosoft web-site. It> > > seems that commits via CVS accounts pipe to the mailing list, but > > you> > > need to be subscribed with that id.> > >> > > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > >> > > > The last commit I got was beginning of April. I think there might> > > > be a wider problem.> > > >> > > >> > > > On 11/08/2007, at 8:54 PM, j k wrote:> > > >> > > >> fyi, I'm not seeing my commits, probably my fault with my screwy-> > > >> for-months-now mail configuration. I do intend to fix it soon...> > > >>> > > >> - Jay> > > >>> > > >> Recharge--play some free games. Win cool prizes too! Play It!> > > >> > >> >> > See what you?re getting into?before you go there See it!> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:27:15 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:27:15 -0000 Subject: [M3devel] new Win32 build from current source Message-ID: Can folks try this? Make it available on the web page?There hasn't been a win32 release for longer than other platforms.I can build "core" and "std" if folks want.These files are directly output from scripts\win\make-dist.cmd. It has the support for "core" and "std", commented out. If folks prefer, tar.gz, .zip, and self extracting .zip are possible; .bz2 is smallest. Perhaps a version number should be in the .tar path structure? The install instructions are like (no cminstall, replaced by using vcvars32.bat which lets one CM3 install move among different tools, debatable which is better) cd /d c:\ optionally rmdir /q/s cm3 tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 run the usual vcvars32.bat or whatever (or use the start menu link that Visual C++ setup creates) set PATH=c:\cm3\bin;%PATH% set LIB=c:\cm3\lib;%lib% optionally, a good test: cd \scripts\win .\do-pkg-std realclean .\do-pkg-std buildship I have not tested the longint stuff and it likely doesn't work yet. The files are in ~jkrell on m3.elegosoft.com: C:\>ssh jkrell at m3.elegosoft.com find . ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 Remember you will need http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 or I could build it with an older toolset if folks want. Thanks, - Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:39:41 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:39:41 -0000 Subject: [M3devel] Some random notes on building/running Modula-3 on Windows (XP). Message-ID: Some of this is redundant -- i.e. has long been working. Some of it is specific to my configuration and habits. You are expected to recognize that. :) I am running Windows XP and currently using Visual C++ 8.0, though many versions of NT and VC should work. Some work has been put into ensuring multiple versions of VC work. Checkout the latest source. Really the latest. (at least of August 12 11am Pacific time). Download and extract the "latest" binary distribution, it is old but ok: cm3-min-WIN32-NT386-5.2.6.tar.bz2 Or maybe it was .gz, I always change them to save space. For me it is at C:\net\modula3\cm3-min-WIN32-NT386-5.2.6.tar.bz2 I install to the default c:\cm3. Prior to running cminstall, mkdir c:\cm3\t. Whenever cminstall asks for a path to a directory, just say c:\cm3\t. (It insists on an existing path, but with my configuration file, which is generic and checked in, none of them are used.) None of these paths matters if you do things this way. After running cminstall, you may rmdir the empty c:\cm3\t. Replace c:\cm3\bin\cm3.cfg with the latest source's cm3\m3-sys\cminstall\src\config\NT386. No edits are necessary. Or, if doing this repeatedly, I have it like so: cm3-min-WIN32-NT386-5.2.6.tar.bz2 is extracted to \net\modula3\cm3-min-WIN32-NT386-5.2.6\t and modified: delete bin\cm3.cfg delete bin\cm3.cfg--default and then to restore just: xcopy /fiveryh \net\modula3\cm3-min-WIN32-NT386-5.2.6\t \cm3 You need /h for hidden because tar will hide files like .M3EXPORTS that start with a dot. t for temp Setup your Visual C++ environment (%PATH%, %LIB%, %INCLUD%) by running the usual vcvars32.bat. For me this is running \env\cm3.vc80.bat (also have \env\cm3.vc20.bat, 40, 41, 42, 50, 60, 70, 71) set LIB=c:\cm3\lib;%LIB% set PATH=c:\cm3\bin;%PATH% Given the source tree at \dev2\cm3.2 I use \dev2 since Unix "takes" \dev. cm3.2 is because cm3 is an older tree I need to get the diffs out of and delete. These instructions are based on Tony's and very similar. Mainly that Windows does not use gcc. cd \dev2\cm3.2\scripts\win @rem make sure %CM3% is clear, in case of running through this stuff multiple times. set CM3= .\do-pkg realclean import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 .\do-pkg buildship import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 set CM3=C:\dev2\cm3.2\m3-sys\cm3\NT386\cm3.exe .\do-cm3-std realclean .\do-cm3-std buildship .\install-cm3-compiler upgrade Alternatively: extract/install/configure latest distribution as above checkout latest source cd scripts\win .\make-dist This gives you: cm3-min-WIN32-NT386-d5.3.2.tar.bz2 cm3-min-WIN32-NT386-d5.3.2-symbols.tar.bz2 buried in temp. I have not tested the new LONGINT functionality and there's a good chance it doesn't work yet. Various GUI apps start up ok. formsedit starts up and show gui. juno starts and shows gui, but crashes easily: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x5aaf8f8 0xf4fc2c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x5aafd54 0xf4db55 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... vorun brings up gui visobliq brings up gui not sure how to exit, had to kill it shownew brings up gui showheap brings up gui showthread brings up gui - Jay _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Mon Aug 13 21:49:17 2007 From: stsp at elego.de (Stefan Sperling) Date: Mon, 13 Aug 2007 19:49:17 -0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813143915.71BE510D4363@birch.elegosoft.com> References: <20070813143915.71BE510D4363@birch.elegosoft.com> Message-ID: <20070813194447.GE1351@ted.stsp.lan> On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 07/08/13 16:39:15 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c > > Log message: > No change to the contents of these files. This is an attempt to get > the time stampof ada-lex.c to be later than that of ada-lex.l. This > will mean m3gdb will build without requiring flex to be installed. What about hacking a 'touch ada-lex.c' into the Makefile somewhere instead? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 12:40:56 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 10:40:56 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: <20070816102225.GA25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? Current head, 5.4, or both? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 13:10:49 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 11:10:49 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816102225.GA25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> Message-ID: <20070816105922.GB25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > > Stefan, could you add the --disable-nls to the gcc configuration and > > try to build a SOLgnu archive? > > Current head, 5.4, or both? Wait a minute... as far as I can tell we already build it with --disable-nls in all cases. Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk has the same): % configure the sources if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "--with-gnu-ld=yes", "&& echo \"done\" > " & done) else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--target=" & GNU_platform (M3CC_TARGET), "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end end -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 16:08:12 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 14:08:12 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> Message-ID: <20070816134458.GD25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 02:54:34PM +0200, Olaf Wagner wrote: > Then I don't understand why the version Alex Bochannek got from > our installation archives needed libiconv.so.2. Any idea? Because m3-sys/m3cc/gcc/gcc/configure.ac depends on it unconditionally. The following is in global scope: AM_ICONV # Until we have in-tree GNU iconv: LIBICONV_DEP= AC_SUBST(LIBICONV_DEP) So I guess the configure script always picks up libiconv if it is present. I'll try to remove the check for libiconv to see if the backend builds without it. The script even bothers to filter out possible multiple occurences of -liconv if --enable-nls is passed (i.e. gcc if is linked to libintl): # If LIBINTL contains LIBICONV, then clear LIBICONV so we don't get # -liconv on the link line twice. case "$LIBINTL" in *$LIBICONV*) LIBICONV= ;; esac The non-iconv case is clearly not intended by the authors of configure.ac... Also, I just checked the cm3cg binary on FreeBSD, it also depends on libiconv, which is not in the base system on FreeBSD either: % ldd /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg: libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28474000) libc.so.6 => /lib/libc.so.6 (0x28561000) -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:32:46 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:32:46 -0000 Subject: [M3devel] AMD64 In-Reply-To: References: Message-ID: <20070816172515.GC15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:32:46 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:32:46 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816171813.GB15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:47:18 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:47:18 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816174655.GD15579@jack.stsp.lan> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. I'd favour listing libiconv as an explicit dependency of cm3. I've looked into this, and --disable-nls is not sufficient to remove gcc's dependency on libiconv. It unconditionally depends on libiconv if it can find the library on the system, regardless of flags passed to the configure script. I've tried hacking iconv detection out of the build system. There's a diff below against cm3-5.4 that removes cm3cg's dependency on libiconv. But it is very ugly. m3gdb also unconditionally depends on libiconv. I have not looked into that. I cannot deinstall libiconv on our Solaris box to prevent configure from picking it up because I don't have root, and I don't really think it's a good idea to begin with because removing the library would probably break a lot of dependencies. Alex, could you provide more details on what gcc backend you are using? Does the ezm3 equivalent of the cm3cg executable depend on libiconv? % ldd /usr/local/cm3/bin/cm3cg libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 With the patch below I get: % ldd /usr/stsp/cm3/bin/cm3cg libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 Index: src/m3makefile =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 m3makefile --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 @@ -126,7 +126,8 @@ if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." + & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", Index: gcc/gcc/Makefile.in =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 @@ -471,8 +471,8 @@ LIBINTL_DEP = @LIBINTL_DEP@ # Character encoding conversion library. -LIBICONV = @LIBICONV@ -LIBICONV_DEP = @LIBICONV_DEP@ +#LIBICONV = @LIBICONV@ +#LIBICONV_DEP = @LIBICONV_DEP@ # The GC method to be used on this system. GGC=@GGC at .o @@ -718,7 +718,7 @@ BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a # Dependencies on the intl and portability libraries. -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) # Likewise, for use in the tools that must run on this machine # even if we are cross-building GCC. @@ -726,7 +726,7 @@ # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:50:37 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:50:37 -0000 Subject: [M3devel] AMD64 In-Reply-To: <20070816172515.GC15579@jack.stsp.lan> References: <20070816172515.GC15579@jack.stsp.lan> Message-ID: <20070816174956.GE15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 07:25:15PM +0200, Stefan Sperling wrote: > <<< No Message Collected >>> > --oTHb8nViIGeoXxdp-- Sorry, local sendmail screw up. Manually messing with the mail queue is not a good idea :-/ Here is the message again: On Thu, Aug 16, 2007 at 01:13:06PM -0400, Tony Hosking wrote: > I seem to recall that someone had been working on a Linux AMD64 target. > I'd like to get that working and would be interested in any progress that's > been made in that direction. That was me. It was more than 2 years ago. The problem back then was that the gcc backend kept segfaulting while trying to bootstrap a native cm3 for amd64. The front end is pretty much done iirc. We anticipated an update of the backend to see if that would fix things. Since you've done the update long ago at this stage, I guess it's worth trying to merge the diff into the current tree, minus the now obsolete system call wrappers in the diff. Maybe things just work. The diff is here: http://www.stsp.name/cm3/cm3-linux-amd64-2005-04-18.patch -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:08:13 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 18:08:13 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816175930.GG15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... Is that because you don't have libiconv installed on your system? -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:10:45 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 18:10:45 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816181004.GH15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:54:55PM -0400, Tony Hosking wrote: > PS Here is how I configured building in m3cc/SOLgnu: > > ../gcc/configure --enable-languages=m3cg --disable-nls --disable-nls makes no difference at all with respect to libiconv. See my previous mail. All --disable-nls does is remove a dependency on libintl. This is not a Solaris-only problem. We can either: 1) Build cm3 releases on boxes that haven't got libiconv installed. 2) Declare libiconv an official dependency of cm3. 3) Hack the dependency on libiconv out of the build systems of cm3cg and m3gdb, and possibly others. 1) is a pain for people making releases. 2) is easy for developers, and nothing changes for users because we've always implicitly depended on libiconv without noticing. I've posted a crude patch that does 3) for cm3cg, but not for m3gdb. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Fri Aug 17 14:44:47 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 17 Aug 2007 12:44:47 -0000 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> Message-ID: <20070817121902.GB10092@jack.stsp.lan> On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: > Stefan, I thought we had resolved this issue at least for Linux and > Solaris setups with the last release. Did we miss something? We link system libraries dynamically on these platforms. It could be that Rodney's own program does not link libraries dynamically, so he gets the warning. This is the diff that introduced dynamic linking on Linux. Note that we explicitly enable dynamic linking on a per-library basis... maybe we should enforce dynamic linking in general? Index: LINUXLIBC6 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cm3/src/config/LINUXLIBC6,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- LINUXLIBC6 6 Aug 2006 12:46:03 -0000 1.7 +++ LINUXLIBC6 1 Sep 2006 13:42:23 -0000 1.8 @@ -98,14 +98,14 @@ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], -% "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms - "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], - "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], - "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], - "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], - "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", +% "LEX-YACC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-ll" ], %-- not on most Linux platforms + "FLEX-BISON" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lfl" ], + "POSTGRES95" : [ "-Xlinker", "-Bdynamic", "-L/usr/local/postgres95/lib", "-lpq" ], + "OPENGL" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], + "MOTIF" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXm" ], + "X11" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], - "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], + "PTHREAD" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rcoleburn at scires.com Fri Aug 17 23:26:31 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Aug 2007 21:26:31 -0000 Subject: [M3devel] A strange link time warning using cm3] In-Reply-To: <46C6045A.6050402@wichita.edu> References: <46C6045A.6050402@wichita.edu> Message-ID: <46C5DA31.1E75.00D7.1@scires.com> >>> "Rodney M. Bates" rodney.bates at wichita.edu> 8/17/2007 4:26 PM >> ( mailto:rodney.bates at wichita.edu> ) .... But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. .... I thought that the buildstandalone() directive in the m3makefile is supposed to cause linking with static libraries. At least that is what happens in cm3 v4.1. Regards, Randy Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 18 04:37:36 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 18 Aug 2007 02:37:36 -0000 Subject: [M3devel] Windows Message-ID: I have the inclination, still working on time and expertise. :) Summarize the layering for me? Which module calls which?Your mention below of the assumption of 32 bit ops at least confirms what I thought I vaguely understood reading through the source. It's just a bunch of pretty dense code without documentation, the sort I write myself when I have the whole program in my head and just need to type it all in as quickly as possible. Would the idea be to use a tagged union for this stack, or to split 64 bits ops into pairs of 32 bit ops? You know, like, does this stack translate "closely" to the generated code, or not? If it does, pairs, if it does not, tagged union. Probably. Similarly, like, all the register dealings need some notion of pairs..? Maybe I should look at the other backend to understand better, if there is an analogous bunch of code. Anyway, I'll try at least this weekend to verify that it's buildable asis, i know that's just a teeny tiny baby step, just push the button to build, a monkey could do it... my expertise is beyond that, but... I suspect tagged union is it, and have to churn a bunch of code to check the type. ugh. lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 bit type). ?? Thanks, - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: Windows> Date: Thu, 16 Aug 2007 12:47:36 -0400> To: jay.krell at cornell.edu; jayk123 at hotmail.com> > I should have realized of course that there is a very simple fix for > compilation on the NT386 target using the native m3back backend! > Simply make LONGINT=Int32. Jay, I have just checked in this very > simple fix to Target.m3 which should permit you to bootstrap a new > cm3 and compile the current CVS head.> > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote:> > > With the current native Windows backend (m3back) blindly assuming > > (without even checking!) that all integer operations are 32-bit, I > > wonder if anyone out there has the expertise, time, or inclination > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > not be *too* hard, but I don't have the time for it now, though I > > would be happy to answer any questions that arise. Unfortunately, > > this reveals that Windows support is withering on the vine, in > > spite of Jay's excellent recent work. As of now, this means that > > Windows can only build CVS sources with the tag > > devel_LONGINT_start. Bridging the gap will require smartening up > > m3back or using the gcc-based backend.> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Aug 22 19:34:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 17:34:37 -0000 Subject: [M3devel] A warning on dtoa.h In-Reply-To: <46CC643E.8000108@wichita.edu> References: <46CC643E.8000108@wichita.edu> Message-ID: Yes, I've been burned by this in the past too. For that reason, all my cm3.cfg files use -O in compile_c instead of -O3. I note that there is an updated dtoa, which perhaps we should be using instead, though I don't know if gcc optimizations still cause issues with it. I seem to recall it was something to do with aliasing, which gcc generates appropriate warnings for. I note that the newer dtoa requires some locking for preemptively- scheduled threads (as our later PTHREAD systems do), so perhaps some work is in order here. Here is the newer dtoa: -------------- next part -------------- A non-text attachment was scrubbed... Name: dtoa.c Type: application/octet-stream Size: 67983 bytes Desc: not available URL: -------------- next part -------------- On Aug 22, 2007, at 12:28 PM, Rodney M. Bates wrote: > I have located a case where dtoa.h (which is in libm3core) gives a > wrong result when compiled by gcc 3.4.3 -O2 but works correctly > with -O0. When compiled by gcc 4.1.1, this case works correctly > with either optimization level. > > Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some > "undefined" code remains to be seen. > > In either case, beware. It caused pm3 to miscompile the REAL constant > 2.0, used in Table.mg, which made an instantiation of Table get a > false > runtime range error. It took days to track down. I had another > instance of a bad real constant being compiled from a long time ago, > that I never diagnosed. > > cm3 uses a virtually identical dtoa.h, and nothing in the call chain > leading up to the instance where I found the problem is materially > changed from pm3 to cm3, so probably cm3 is affected in the same > way. > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Aug 26 14:22:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:22:17 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: still no int64/longint support, but there's another build in ~jkrell on m3.elegosoft.comanyone want to try it?Jay at jay-win8 ~$ find ../cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2./cm3-min-WIN32-NT386-d5.5.0.tar.bz2Jay at jay-win8 ~$ pwd/home/Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 26 14:25:26 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:25:26 +0000 Subject: [M3devel] webscape crash Message-ID: I can't seem to get the hang of any of the modula-3 gui apps. They all look a bit clunky and act wierd or don't do much. Probably QT or GTk or wxWindows "bindings" are in order.. (QT is my pick..)mentor doesn't do much.deckscape and webscape don't much.I was able to crash webscape pretty quickly.0:014> .lasteventLast event: 4c4.5c0: Access violation - code c0000005 (first chance) debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7)0:014> u .m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]:005610b4 8b5e00 mov ebx,dword ptr [esi]005610b7 8b5300 mov edx,dword ptr [ebx]005610ba 8955e0 mov dword ptr [ebp-20h],edx005610bd 8d7de8 lea edi,[ebp-18h]005610c0 57 push edi005610c1 56 push esi005610c2 83fa00 cmp edx,0005610c5 750a jne m3core!RTHooks__Concat+0x8d (005610d1)0:014> r esiesi=000000000:014> kChildEBP RetAddr0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ 173]0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97]0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41]0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271]0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 [WebVBT.m3 @ 182]0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225]0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124]0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 [ThreadWin32.m3 @ 583]0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a [ThreadWin32.m3 @ 548]WARNING: Stack unwind information not available. Following frames may be wrong.0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b40:014> |. 0 id: 4c4 create name: WebScape.exe0:014> _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 03:18:43 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 01:18:43 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: details.. :) > From: hosking at cs.purdue.edu> Date: Sun, 26 Aug 2007 11:38:52 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > PS There is LONGINT support for NT386, but it is just 32-bit, not > 64-bit, so no improvement over INTEGER.> > > On Aug 26, 2007, at 8:22 AM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 27 03:55:36 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 26 Aug 2007 21:55:36 -0400 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: <46D1F6E3.1E75.00D7.1@scires.com> Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 07:30:05 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 05:30:05 +0000 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: Randy, This is good to hear. Btw, there is no guaranteed of short names being available. You can do: fsutil behavior set disable8dot3 1 Btw, short names can be longer than long names, but true they can't have spaces. What a hack..C:\>mkdir \1.1.1 C:\>dir /x /ad 1*08/26/2007 10:10 PM 112E5D~1.1 1.1.1 The notion of passing a run of strings on a flat command line string with spaces between them when the items can have spaces in the first place is obviously broken. You can play with quoting, but then it's a never ending cycle of guessing how many times the quotes are going to be processed and with which rules. The right way to pass an array of strings around is to actually pass an array of strings.. Oh well.. Still I guess changing cm3 to try to use them in some cases might be a reasonable idea. I guess nobody cares on Unix about the spaces? I don't have any spaces, like in running the compiler or linker because 1) I install to \msdev\, none of the \program files places 2) by depending on %path% search. The current source does build with the latest released binaries, if you build in the right order and such. cm3\scripts\win\make-dist.cmd works. Somewhat precisely, from memory, you can do like: rmdir /q/s \cm3 extract latest distribution to \cm3 -- the system.tgz file. You don't need to run the cminstall.exe. cvs checkout to \dev2\cm3 copy \dev2\cm3\m3-sys\cminstall\src\config\nt386 \cm3\bin\cm3.cfg You don't need to edit the file at all, you just need %PATH%, %INCLUDE%, and %LIB% set. There are tradeoffs either way. This lets you changed Visual C++ toolsets by starting a new cmd and running another vcvars32.bat, instead of using a different cm3 configuration file. set some environment variables, mainly put cm3.exe in %PATH% and run the vcvars32.bat or such that Visual C++ includes, or start the Visual C++ command prompt from the start menu. cd \dev2\cm3\scripts\win .\make-dist This will give you something like (it will tell you exactly) %temp%\cm3\\cm3-5.5.0-min.tar.bz2 rmdir /q/s \cm3 extract the cm3-5.5.0-min.tar.bz2 to \cm3 If folks wants a .zip or a self expanding .zip, that is easily done. Tar.bz2 is reliably significantly smaller. Again cd to \dev2\cm3\scripts\win and run make-dist, or better yet do-cm3-std realclean and do-cm3-std buildship. As to the actual stability, I can't say. It is enough to build itself and then use that to build more stuff. I'm afraid I haven't looked at the cm3 gui stuff much. It seems very clunky. I guess we'll have to debug or compare the old and new source. I do remember seeing some questionable commits, like claims that Windows behavior had changed or that the author didn't know what was going but that some strange thing seemed to help. Windows really has a huge compatibility burden and the comments I thought were suspicous. Something around processing keystrokes and something around the environment variables passed to main. 4.1 is the old latest commercial release?I have that. I doubt it will build the current source. There is a file describing how to bootstrap from the older 3.6 release I think. I have not tried that. I believe WIDETEXT and WIDECHAR and such cause problems. Perhaps the compiler should use a strict subset of Modula-3 buildable with particular releases? The problem is probably a blurry line between compiler and runtime and the need to actually implement new features causing some circular dependency?? That's excellent about getting more of the source released. I had no idea what that would take. > same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP) Do folks still care about Win9x? 95? VC 8.0 binaries do not work on 95 for small reasons like use of IsDebuggerPresent and InterlockedCompareExchange. These are easily worked around if folks desire, or use an older toolset. (I didn't find Reactor all that impressive but ok. It is nice to hyperlink all the source, but it was hardly an IDE.) - Jay Date: Sun, 26 Aug 2007 21:55:36 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] cm3 on Windows, plus "Reactor" sources Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSPSenior Systems Engineer, Communications, Networks, & Electronics Division (CNE)Corporate & Atlanta Information Systems Security Manager (ISSM)Scientific Research Corporation2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:04:53 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:04:53 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: simple answer and sufficient: "free" Visual C++ 8.0 compiler and linker search the web for "visual C++ express edition" => http://msdn2.microsoft.com/en-us/express/aa700735.aspx You don't need the IDE, so I don't /think/ you have to "register". Once you install it, the shortcut on the start menu to a cmd with some environment variables set is useful. I wrap it up in my own "environment" .cmd files, like \env\ms\vc80.bat and \env\cm3.vc80.bat (which uses \env\cm3.bat) TBD making these available to folks. They aren't quite generic but they are somewhat. The redist. Search the web for "Visual C++ redist" or "vcredist_X86.exe" => http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en or search for "vcredist_X86.exe sp1" or => http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en probably a Windows Platform SDK, not sure (and certainly not with the non-free Visual C++) search the web for "Windows Platform SDK" => http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en or => http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en I'm not even sure this is needed. Pretty much version will do, probably even the non-Microsoft ones such as ship with Mingwin/cygwin/openwatcom. The dependencies are fairly light, the Modula-3 system tries to be fairly self contained. more generally: I did some testing and applied some fixes with a range of toolsets: Visual C++ 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0. They should all work. You can get any of them from www.ebay.com. 7.1 used to be a free download. There is a beta out of 9.0 already. The binaries where built with 8.0 and so don't work on Windows 95 and require the redist. If folks really don't like that, there are alternatives, such as using libcmt.lib or using older toolsets, but using 8.0 and the redist and dropping Windows 95 seems very reasonable. I am /somewhat/ interested in adding support for other toolsets, like maybe www.openwatcom.com.And/or heck finish the work in CM3 on cutting the linker dependency, either write a linker in Modula-3 or load up the .objs at runtime. Oh, and tar and bzip2. I use the Cygwin versions. tar accepts the "j" flag to decompress bzip2. so like: rmdir /q/s \cm3 mkdir \cm3 cd \cm3 tar tjvz foo.tar.bz2 add \cm3\bin to %PATH% .tar.gz, .zip, self extracting .zip are all trivial to provide if tar/bzip2 is really an onerous dependency. .tar.bz2 is consistently and significantly smaller. The "support", like all of 2 lines of code, is in cm3\scripts\win\make-dist.cmd. - Jay > From: darko at darko.org> Date: Mon, 27 Aug 2007 07:39:14 +0200> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > I'm interested, but what windows tools does it require?> > > On 26/08/2007, at 2:22 PM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:19:52 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:19:52 +0000 Subject: [M3devel] platform names? Message-ID: Anyone want to propose platform names? Adopt a "system" where "OS", toolset, runtime, processor, and/or pointer size are clear, or just keep using short CAPS informal non-systematic names? NT386Wat? NT386WAT?? <== seems most likely given the current short informal CAPS non-systematic pattern NT386WATCOM? NT386Watcom? NTx86Watcom? Win32-x86-watcom? win-x86-openwatom1.7? NTAMD64? <== seems most likely given the current short informal CAPS non-systematic pattern NTIA64? win64-amd64-msc? (msc -- toolset and runtim, vs. say GNU or Watcom) win-amd64-msc? (drop "64" in favor of architecture, leaving win-x86 ambiguous though -- win-286, win-386?) win16? win64? Or just win + architecture or nt + architecture? Way too ambiguous. There is IA64 and there was Alpha64. Consider there is also Windows CE. win-mips? win-powerpc? wince-powerpc?winnt-powerpc? msnt-powerpc? msce-powerpc? msce-arm? (msc -- "Microsoft C" -- toolset and runtime) I am not suggesting developering support for any of these mind you. Which reminds me -- most of the architectures are dead. Should they be deleted? Resusicated? Resusicated if gcc supports them? Do nothing? I know I know, 64 bit integer support on NT386 is the most important thing to do right now. - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 19:55:21 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:55:21 -0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Aug 3 01:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Aug 2007 19:35:08 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <7AAE9AC9-2D63-49F6-8CB5-CD72E5EBF2FB@cs.purdue.edu> I'm pretty sure my latest checkins fix the remaining issues with pthread threading. Please let me know of any further problems. mentor now works reliably for me -- YAY! On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> but after recompiling a second time, it no longer seems to do that. >>> By the way, I am somewhat suspicious that this Juno crash has >>> something to do with threading: if you look closely, that part of >>> Juno has to do with thread switching into and out of the >>> Juno-machine...which is why I was happy to see it disappear (however >>> it did that). >> >> Maybe you had stale code in the build directories? Glad to hear it >> went away after recompiling. >> > > I *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 >>> *** >>> >> >> That is an assert regarding setting the stack size. I wonder if this >> is a Thread.SizedClosure which has a size value that asks for a stack >> size less than PTHREAD_STACK_MIN. I am not sure what the best way to >> handle that is except to disregard the return value from >> pthread_attr_setstacksize. Can you try replacing line 675 in >> ThreadPThread.m3 with: >> >> EVAL Upthread.attr_setstacksize(attr, bytes); >> >> and rebuilding? I am surprised to see that error though, since you >> will note that I get the default stack size from a freshly >> initialized attributes structure on line 673 and use the greater of >> the default size and the requested size. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. > >> Weird, I was running Bresenham just fine yesterday after the fix I >> checked in. Sounds like you may have some stale object files lying >> around. > > I was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). > >> >>> I really don't think it's my old system that's corrupting the new >>> images, >>> but I am *never* 100% certain of that. I found a very weird >>> behavior >>> with the build system, actually. I found that the not-yet-installed >>> compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in >>> /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is >>> that >>> a known/desired behavior? It causes the brand new compiler to >>> use the >>> old cm3.cfg, and it does so quietly without any warnings or messages >>> whatsoever. Changing your PATH makes it stop do that and instead >>> crash, >>> prompting me to put the cm3.cfg I want in the right place... >> >> I was not aware that you are mixing cm3.cfg versions. Why do you >> need both an old and a new one? In any case, this suggests that you >> want to rebuild the new system using the proper cm3.cfg and see if >> your problems go away. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. > > > Mika From hosking at cs.purdue.edu Tue Aug 7 23:48:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 17:48:52 -0400 Subject: [M3devel] LONGINT Message-ID: Shortly I will be checking in compiler and run-time updates that enable the LONGINT type: 32 <= BITSIZE(INTEGER) <= BITSIZE(LONGINT) <= 64 Here are the changes to the language spec, in the form of context diffs to the updated reference manual, which is available at http:// www.cs.purdue.edu/~hosking/m3/reference/index.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diffs Type: application/octet-stream Size: 15769 bytes Desc: not available URL: -------------- next part -------------- I have gone for the minimalist approach to adding LONGINT to the language. In brief, LONGINT is a distinct ordinal type from INTEGER. Conversions can be performed using ORD and VAL. For LONGINT 'n', ORD(n) converts n to an INTEGER. For INTEGER 'n', VAL (n, LONGINT) converts n to a LONGINT. Implicitly, this means all enumerations have an underlying INTEGER representation. LONGINT subranges work as expected. Open arrays are indexed by INTEGER values. Fixed arrays can have an index type whose base type is LONGINT. The rest of the changes to the language spec flow from these fundamentals. From hosking at cs.purdue.edu Wed Aug 8 00:05:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:05:03 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: Just responding to this w.r.to what I have implemented. On Jul 19, 2007, at 5:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? You can use a subrange of LONGINT for array indexes. The effective offset of an array element is still computed as an integer. Arrays are restricted in size, as they are currently. > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. Integers and addresses have the native word size. > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. I have done this. > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > 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 Wed Aug 8 00:07:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:07:08 -0400 Subject: [M3devel] LONGINT In-Reply-To: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> Message-ID: I allow LONGINT indexed arrays, so long as the element offset can be computed as an integer. The size restriction on arrays remains. NUMBER always returns a CARDINAL. Thus, NUMBER(LONGINT) gives a range violation, just as NUMBER(INTEGER) currently does. However, NUMBER([10L .. 20L]) = NUMBER([10..20]) = 11. On Jul 19, 2007, at 6:02 PM, Darko wrote: > I think in 64 bit land you get a variety of combinations and > possibly the most common is a 32 bit address space with 64 bit > integers, since applications seldom need to operate in the larger > address space. But I would think it you wouldn't allocate an object > bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would > be more likely. > > The only situation where I can think of where this is an issue is > using a long integer index in an array of integer proportions, you > could handle this using arithmetic, also illustrates where you'd > need an implicit conversion: > > CONST > start = 2^63-500; > end = 2^63-200; > VAR > a: ARRAY[0..start-end+1] OF CHAR; > BEGIN > FOR i := start TO end DO a[INT(i-start)] := 'x' END; > > > Or you could rule that all arrays are of INTEGER size, but may have > a LONGINT index. Open arrays would always be integers. This would > probably be messy to implement and NUMBER would have a different > base to FIRST and LAST. That doesn't sound very good. > > > > On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > >> >> >> Randy Coleburn wrote: >>> Tony: >>> I'd like to better understand the implications of your change as >>> I do use LONGINT as an index in some applications. >> >> Do you have arrays that need 64-bit subscripts on a 32-bit machine? >> >> Allow me the common assumption that both integers and addresses have >> the native word size on most machines. In this case, most arrays >> that >> need 64-bit subscripts would exceed the virtual address space of the >> machine. Exceptions would require elements of size at most a byte, >> and overall sizes in excess of half the virtual address space. Even >> PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the >> virtual space before 32-bit subscripts ran out. All this seems >> pretty >> unlikely. >> >> I would favor keeping INTEGER as the type of open array subscripts >> and not allowing LONGINT to be a fixed array subscript type. It >> saves a whole lot of language complexity, and doesn't disallow much. >> >> If it really mattered, you could still use unsafe techniques for >> such memory-hogging arrays. This might be a reason to extend unsafe >> arithmetic on ADDRESS to accept LONGINT second operands. This is >> actually consistent with the rest of the operator generalizations. >>> >> >> -- >> ------------------------------------------------------------- >> 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 Wed Aug 8 05:59:12 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 23:59:12 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems Message-ID: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Now I've checked in the LONGINT extensions, I am wondering if we shouldn't observe the following protocol for mapping INTEGER and LONGINT to C types. Currently, we have the following: 32-bit targets 64-bit targets INTEGER 32 bits 64 bits LONGINT 64 bits 64 bits C long int 32 bits 32 bits C long long 64 bits 64 bits I wonder if we shouldn't simply identify INTEGER as 32-bit and LONGINT as 64-bit on all targets. That way, INTEGER=long int and LONGINT=long long. Comments? From hosking at cs.purdue.edu Wed Aug 8 14:39:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:39:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> References: <20070808035016.A852410D440E@birch.elegosoft.com> <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Message-ID: <0B1FC476-C32B-4E57-8DC7-2856E85C1EF8@cs.purdue.edu> Make sure to start with clean build directories and clean before building with the bootstrapped compiler... On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > Amended bootstrap instructions: > > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3cc > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts ./do-cm3-std.sh realclean > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 07/08/08 05:50:13 >> >> Modified files: >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html >> for.html index.html m3.html m3index.html >> numbers.html ordinal.html subtypes.html >> typeops.html word-intf.html >> cm3/m3-db/smalldb/src/: OSSupport.m3 >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 >> SocketPosix.m3 >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 >> cm3/m3-libs/m3core/src/thread/: m3makefile >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 >> Utypes.i3 >> m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/word/: m3makefile >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> cm3/m3-sys/m3front/src/: m3makefile >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 >> Dec.m3 First.m3 Floatt.m3 >> Floor.m3 Inc.m3 Last.m3 >> Max.m3 New.m3 Number.m3 >> Ord.m3 Round.m3 Subarray.m3 >> Trunc.m3 Val.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 >> m3makefile >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 >> WordInsert.m3 WordModule.m3 >> WordNot.m3 WordOr.m3 >> WordRotate.m3 WordShift.m3 >> WordXor.m3 >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 >> CastExpr.m3 CheckExpr.m3 >> CompareExpr.m3 DivExpr.m3 >> EqualExpr.m3 Expr.m3 ExprParse.m3 >> InExpr.m3 IntegerExpr.i3 >> IntegerExpr.m3 ModExpr.m3 >> MultiplyExpr.m3 NegateExpr.m3 >> ReelExpr.i3 ReelExpr.m3 >> SetExpr.m3 SubscriptExpr.m3 >> SubtractExpr.m3 >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 >> Marker.m3 Scanner.m3 TipeDesc.i3 >> TipeDesc.m3 Token.i3 Token.m3 >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 >> ForStmt.m3 TryFinStmt.m3 >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 >> OpenArrayType.m3 SubrangeType.m3 >> Type.i3 Type.m3 >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 >> Module.m3 Variable.m3 >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 >> TWord.i3 TWord.m3 Target.i3 Target.m3 >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 >> M3Lexer.m3 M3Type.i3 M3Type.m3 >> cm3/m3-tools/m3browser/src/: Main.m3 >> Added files: >> cm3/doc/reference/: m3logo.gif >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 >> LongDivide.i3 LongDivide.m3 >> LongExtract.i3 >> LongExtract.m3 LongGE.i3 >> LongGE.m3 LongGT.i3 >> LongGT.m3 LongInsert.i3 >> LongInsert.m3 LongLE.i3 >> LongLE.m3 LongLT.i3 >> LongLT.m3 LongMinus.i3 >> LongMinus.m3 LongMod.i3 >> LongMod.m3 LongModule.i3 >> LongModule.m3 LongNot.i3 >> LongNot.m3 LongOr.i3 >> LongOr.m3 LongPlus.i3 >> LongPlus.m3 LongRotate.i3 >> LongRotate.m3 LongShift.i3 >> LongShift.m3 LongTimes.i3 >> LongTimes.m3 LongXor.i3 >> LongXor.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 >> >> Log message: >> Compiler and runtime extensions to support LONGINT type. >> >> Bootstrapping instructions: build and ship packages in the >> following order >> >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. >> >> Use this new compiler to build and ship the new system: >> >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 >> cd cm3/scripts >> ./do-cm3-std.sh buildship >> >> If this is successful then move the new compiler to BINDIR: >> >> mv $CM3 INSTALL_DIR/bin/cm3 > From hosking at cs.purdue.edu Wed Aug 8 14:31:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:31:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070808035016.A852410D440E@birch.elegosoft.com> References: <20070808035016.A852410D440E@birch.elegosoft.com> Message-ID: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Amended bootstrap instructions: Compiler and runtime extensions to support LONGINT type. Bootstrapping instructions: build and ship packages in the following order m3cc m3middle m3linker m3front m3quake cm3 This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. Use this new compiler to build and ship the new system: export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 cd cm3/scripts ./do-cm3-std.sh buildship If this is successful then move the new compiler to BINDIR: mv $CM3 INSTALL_DIR/bin/cm3 On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 07/08/08 05:50:13 > > Modified files: > cm3/doc/reference/: arithmetic.html arrays.html conventions.html > for.html index.html m3.html m3index.html > numbers.html ordinal.html subtypes.html > typeops.html word-intf.html > cm3/m3-db/smalldb/src/: OSSupport.m3 > cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > SocketPosix.m3 > cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > cm3/m3-libs/m3core/src/thread/: m3makefile > cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > Utypes.i3 > m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/word/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/: m3makefile > cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > Dec.m3 First.m3 Floatt.m3 > Floor.m3 Inc.m3 Last.m3 > Max.m3 New.m3 Number.m3 > Ord.m3 Round.m3 Subarray.m3 > Trunc.m3 Val.m3 > cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > m3makefile > cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > WordInsert.m3 WordModule.m3 > WordNot.m3 WordOr.m3 > WordRotate.m3 WordShift.m3 > WordXor.m3 > cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > CastExpr.m3 CheckExpr.m3 > CompareExpr.m3 DivExpr.m3 > EqualExpr.m3 Expr.m3 ExprParse.m3 > InExpr.m3 IntegerExpr.i3 > IntegerExpr.m3 ModExpr.m3 > MultiplyExpr.m3 NegateExpr.m3 > ReelExpr.i3 ReelExpr.m3 > SetExpr.m3 SubscriptExpr.m3 > SubtractExpr.m3 > cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > Marker.m3 Scanner.m3 TipeDesc.i3 > TipeDesc.m3 Token.i3 Token.m3 > cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > ForStmt.m3 TryFinStmt.m3 > cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > OpenArrayType.m3 SubrangeType.m3 > Type.i3 Type.m3 > cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > Module.m3 Variable.m3 > cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > TWord.i3 TWord.m3 Target.i3 Target.m3 > cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > M3Lexer.m3 M3Type.i3 M3Type.m3 > cm3/m3-tools/m3browser/src/: Main.m3 > Added files: > cm3/doc/reference/: m3logo.gif > cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > LongDivide.i3 LongDivide.m3 > LongExtract.i3 > LongExtract.m3 LongGE.i3 > LongGE.m3 LongGT.i3 > LongGT.m3 LongInsert.i3 > LongInsert.m3 LongLE.i3 > LongLE.m3 LongLT.i3 > LongLT.m3 LongMinus.i3 > LongMinus.m3 LongMod.i3 > LongMod.m3 LongModule.i3 > LongModule.m3 LongNot.i3 > LongNot.m3 LongOr.i3 > LongOr.m3 LongPlus.i3 > LongPlus.m3 LongRotate.i3 > LongRotate.m3 LongShift.i3 > LongShift.m3 LongTimes.i3 > LongTimes.m3 LongXor.i3 > LongXor.m3 > cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > Log message: > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 From darko at darko.org Wed Aug 8 15:30:22 2007 From: darko at darko.org (Darko) Date: Wed, 8 Aug 2007 15:30:22 +0200 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Message-ID: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> This might make sense as a platform option (ie where more than one platform config is available), where 32 bit integer performance is better, or you want to save memory. But INTEGERs are fairly fundamental. For instance, you might actually legitimately want to allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER wouldn't work on it. Will a integer subrange of a 64 bit INTEGER get handled by the back end as efficiently as a 'natively' defined 32 bit integer which is logically defined as a subrange? On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > Now I've checked in the LONGINT extensions, I am wondering if we > shouldn't observe the following protocol for mapping INTEGER and > LONGINT to C types. Currently, we have the following: > > > 32-bit targets 64-bit targets > > INTEGER 32 bits 64 bits > LONGINT 64 bits 64 bits > C long int 32 bits 32 bits > C long long 64 bits 64 bits > > I wonder if we shouldn't simply identify INTEGER as 32-bit and > LONGINT as 64-bit on all targets. That way, INTEGER=long int and > LONGINT=long long. > > Comments? > From rodney.bates at wichita.edu Wed Aug 8 17:20:48 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 10:20:48 -0500 Subject: [M3devel] No m3commit mailing list messages Message-ID: <46B9DF50.20608@wichita.edu> I have made three commits to m3gdb files inside the cm3 repository, on July 13, Aug 5 and Aug. 6. At least the first two seem to have gotten in to the repository, but there are no commit messages to this list. I had a delivery quota problem for a few days around the end of July, but I have checked the list archives via the web, and there are no messages there either. -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Wed Aug 8 21:30:32 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 08 Aug 2007 21:30:32 +0200 Subject: [M3devel] No m3commit mailing list messages In-Reply-To: <46B9DF50.20608@wichita.edu> References: <46B9DF50.20608@wichita.edu> Message-ID: <46BA19D8.1070108@elegosoft.com> You're right. You were not subscribed with rodney at elego.de which is the from address when you commit to our repository. I'm sorry, the person who created the subscriptions might have forgotten this address. Your messages should appear now though. Regards, Ronny Rodney M. Bates schrieb: > I have made three commits to m3gdb files inside the cm3 repository, > on July 13, Aug 5 and Aug. 6. At least the first two seem to have > gotten in to the repository, but there are no commit messages to > this list. I had a delivery quota problem for a few days around > the end of July, but I have checked the list archives via the web, > and there are no messages there either. > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Aug 9 01:10:30 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:10:30 -0500 Subject: [M3devel] Different forms of the language definition Message-ID: <46BA4D66.6040507@wichita.edu> I checked in a .tex, a one-page .html, and a .ps version of the Modula-3 language definition, with the intent to get them consistent with each other and the multi-page html version. Does anyone have any ideas about the best way to derive the different forms from a single source, or how it was originally done? I personally don't find an on-line form very usable, and printing multiple html pages is both tedious to do and rather bad-looking to use. Even a paper print of the one-page html form doesn't look great. My favorite is a .ps or .pdf. But the .ps I had and checked in appears to be been converted from a one-page html form and looks like a print from a web browser. I can easily produce a nice .ps from the .tex with Latex. I am sure some will prefer other forms than I do. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 9 01:20:22 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:20:22 -0500 Subject: [M3devel] Threads summary for m3gdb Message-ID: <46BA4FB6.5090807@wichita.edu> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- 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 rcoleburn at scires.com Thu Aug 9 01:27:55 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 08 Aug 2007 19:27:55 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <46BA192B.1E75.00D7.1@scires.com> Rodney: I believe that on Windows (Win32) the implementation uses native OS threads. At least that is how it worked for cm v4.1. Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Aug 9 10:50:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:50:12 +0200 (CEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: <41532.194.138.127.36.1186649412.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:10, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? It's been some years since I've done it, but you can use LaTeX as source and produce high-quality PS and PDF output (dvips, dvipdf) as well as HTML (there were several tools at the time). Alternatively you could use DocBook/SGML tools (as for example the FreeBSD project does (at least, did some years ago ;-)). Personally I'd think LaTeX is fine and will be easier. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 9 10:53:53 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:53:53 +0200 (CEST) Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <45691.194.138.127.36.1186649633.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:20, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. This is true for the POSIX platforms; on Windows, always native system threads have been used. > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. Pthreads interfaces may be mapped to kernel threads, depending on the operating system and its configuration. > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. I don't think this is correct. GC changes are independent of the threads changes (though both were done by Antony Hosking). He may correct me of course. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? See above, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Aug 9 15:02:49 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 09 Aug 2007 15:02:49 +0200 (MEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: On Wed, 8 Aug 2007, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? > > I personally don't find an on-line form very usable, and printing multiple > html pages is both tedious to do and rather bad-looking to use. Even a > paper print of the one-page html form doesn't look great. My favorite is > a .ps or .pdf. But the .ps I had and checked in appears to be been > converted from a one-page html form and looks like a print from a web > browser. I can easily produce a nice .ps from the .tex with Latex. The PostScript version I downloaded from somewhere years ago looked like generated with TeX (at least not from HTML). I think this is the way to go. From hosking at cs.purdue.edu Fri Aug 10 05:42:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:42:51 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> Message-ID: <7C34CE31-81ED-4488-B0A2-D34D13CC0E0F@cs.purdue.edu> On Aug 8, 2007, at 9:30 AM, Darko wrote: > This might make sense as a platform option (ie where more than one > platform config is available), where 32 bit integer performance is > better, or you want to save memory. But INTEGERs are fairly > fundamental. For instance, you might actually legitimately want to > allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER > wouldn't work on it. On second thoughts.... Given how integer is intimately tied up with Word.T and many assume BITSIZE(INTEGER)=BITSIZE(ADDRESS) I think we probably want INTEGER left as it currently stands. > Will a integer subrange of a 64 bit INTEGER get handled by the back > end as efficiently as a 'natively' defined 32 bit integer which is > logically defined as a subrange? Currently subranges with LONGINT base have values represented as LONGINT. A subrange of LONGINT can be used as an array index for an array, so long as NUMBER(array) is restricted, just as it is currently. > > > > On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > >> Now I've checked in the LONGINT extensions, I am wondering if we >> shouldn't observe the following protocol for mapping INTEGER and >> LONGINT to C types. Currently, we have the following: >> >> >> 32-bit targets 64-bit targets >> >> INTEGER 32 bits 64 bits >> LONGINT 64 bits 64 bits >> C long int 32 bits 32 bits >> C long long 64 bits 64 bits >> >> I wonder if we shouldn't simply identify INTEGER as 32-bit and >> LONGINT as 64-bit on all targets. That way, INTEGER=long int and >> LONGINT=long long. >> >> Comments? >> From hosking at cs.purdue.edu Fri Aug 10 05:58:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:21 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <62EDD983-A3B8-4A11-B1F5-2636FB977A70@cs.purdue.edu> On Aug 8, 2007, at 7:20 PM, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. Yes, though this needs migration to using getcontext/setcontext/ makecontext instead so as to work properly on systems that implement secure setjmp/longjmp. > The new system, called for by -DPTHREAD uses the pthreads library > instead. Yes. gdb handles pthreads on most systems. > There is no use of any kind of kernel threads. pthreads are usually scheduled as a thin veneer over kernel threads. For example, there is a 1-1 map between pthreads and Mach threads on Darwin (similarly for Solaris and Linux). > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. Not true. The old thread system works fine with the new GC. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. Not true. The new GC works fine with the old threads system. > Is this all correct? Hope this helps. > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 05:58:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:51 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA192B.1E75.00D7.1@scires.com> References: <46BA4FB6.5090807@wichita.edu> <46BA192B.1E75.00D7.1@scires.com> Message-ID: <9BAA4292-AD96-43DD-A3C8-0DA4F89D9C4B@cs.purdue.edu> Yes, on Win32, M3 threads are win32 threads. On Aug 8, 2007, at 7:27 PM, Randy Coleburn wrote: > Rodney: > > I believe that on Windows (Win32) the implementation uses native OS > threads. At least that is how it worked for cm v4.1. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > H! ere's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. > > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. > > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. > > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 10:11:24 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Aug 2007 10:11:24 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: Message-ID: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> On Fri, August 10, 2007 01:57, Alex Bochannek wrote: > A couple of quick comments about the CM3 build process on Solaris/SPARC. > > 1) /usr/local/cm3 is hardcoded in a few places in sysinfo.sh. I > installed the minimal binaries in /opt/cm3 and needed to change > sysinfo.sh. I would be surprised if that would be all; supporting other installation locations by the simple build scripts has really not been a target until now. Improvements are always welcome though, so if you have patches that make this abstraction they're sure to get included. > 2) cm3cg is linked against libiconv.so.2. This is not a standard Solaris > library, at least not on Solaris 10. I will install the GNU libiconv and > see if that works. cm3cg is the standard GNU compiler backend, so it may need some (ever increasing) infrastructure (i.e. other GNU libraries). We should either declare this as an explicit dependency (i.e. installation prerequisite) or include it in our installation archives. Probably it hasn't been missing for anybody else using M3 so far, because gcc was always installed before. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Aug 11 15:55:14 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 13:55:14 +0000 Subject: [M3devel] compiling the C code as C++? Message-ID: I was going through diffs I had around. One set is mostly putting #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif around all the C code, and a little something for the K&R code. The point was to compile all the C code as C++. I assume I had it working but I'll have to get back up to speed to verify that. Thoughts? - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:26:56 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:26:56 +0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? Message-ID: I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really? Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some. Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history". All you need is the following: signed and unsigned integer types that are exactly 8 bits in size signed and unsigned integer types that are exactly 16 bits in size signed and unsigned integer types that are exactly 32 bits in size signed and unsigned integer types that are exactly 64 bits in size signed and unsigned integer types that are exactly the size of a pointer 10 integer types total, named something like: INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit: int => INT => INT_PTR unsigned => UINT => UINT_PTR DWORD => DWORD_PTR convert to the upper case types if not there, and append "_PTR" The existing types size_t and ptrdiff_t did change size. If someone really needed 32 bit types there, you'd have to change your code. Windows has more than that for historical and stylistics reasons -- upper case types, lowercase types, types that "favor" being unsigned int or unsigned long. Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary. C 9x adds in "fast" and "small" types types that are the smallest type that is at least a certain size, I think types that are the fastest type that are at least a certain size, I think the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out beyond necessity. Yeah, obviously, they seem like maybe you might want them, but it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient to use on all forseeable processors, since tons of code uses them, and people should not will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are mostly stupid these days and they very often should be widened, but folks can do that "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used. Why has this been so hard in Modula-3? Is it that "Word" is widely used and has been pointer sized? Or that INTEGER has been widely used and sometimes assumed to be pointer sized? Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but weren't done right and there is some legacy we are stuck with?? Do "subrange" types make it all confusing? Or merely the assignment rules among the non subrange integer types? I have not paid particularly close attention; it just has always surprised me that it was difficult to work out what to do. I guess it is all moot now, the issues have been worked out and the feature is there. Good. I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly abstracted C names "short", "int", "long" are a useful abstraction. I think you really want the 10 base types I first listed. btw, even the types that are same size as a pointer are overused in C/C++. You don't need them for as much pointer arithmetic as people use. You can use "char*" for that. They are useful for array indices though, the result of wcslen, sizeof(), etc. File sizes should always be UINT64.. - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 17:15:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 11:15:06 -0400 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> I think you have reasonably illustrated just why C/C++ is such a mess. In M3 we have "BITS n FOR ..." to get appropriately sized things, equivalent to C/C++ char, short, long, long long. The split between INTEGER and LONGINT is unfortunate perhaps, but represents an explicit signal to programmers that INTEGER and LONGINT have different underlying representations, which is in the spirit of Modula-3's existing type system. Perhaps we should be explicit in the C type mappings for M3 by writing: char = BITS 8 FOR ... short = BITS 16 FOR ... int = BITS 32 FOR ... long_long = BITS 64 FOR ... On Aug 11, 2007, at 10:26 AM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! From darko at darko.org Sat Aug 11 17:17:15 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:17:15 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <3AAAC6BE-6742-4B5C-882F-980D1DA39D00@darko.org> The point of M3 is not be different than some other language, the point is for it to be safe, and, as a side effect, easy to use. Making a language safe is hard becuase you have to consider every possible usage and outcome becuase the language guarantees that it will not produce an "unchecked" error for the safe subset of the language, that is, it will do something random no matter how use use the language. So we have to consider all changes very carefully. On 11/08/2007, at 4:26 PM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 17:26:44 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:26:44 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> References: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> Message-ID: <74C18A3E-B31F-4D95-AF21-81A770F86B7E@darko.org> INTEGER in M3 is much more abstract than C, you can use it largely without thinking about what size it is, or at least you should. Portability and simplicity are other benefits you get with M3 compared to C++. On 11/08/2007, at 5:15 PM, Tony Hosking wrote: > I think you have reasonably illustrated just why C/C++ is such a > mess. In M3 we have "BITS n FOR ..." to get appropriately sized > things, equivalent to C/C++ char, short, long, long long. The > split between INTEGER and LONGINT is unfortunate perhaps, but > represents an explicit signal to programmers that INTEGER and > LONGINT have different underlying representations, which is in the > spirit of Modula-3's existing type system. Perhaps we should be > explicit in the C type mappings for M3 by writing: > > char = BITS 8 FOR ... > short = BITS 16 FOR ... > int = BITS 32 FOR ... > long_long = BITS 64 FOR ... > > On Aug 11, 2007, at 10:26 AM, j k wrote: > >> I know, like, the point of Modula-3 is to not be like C or C++ and >> to revisit everything in them, but..really? >> >> Windows programming in C and C++ has had this solved reasonable >> for MANY YEARS. >> Other folks solved it similarly even longer ago, though I would >> claim Windows's >> approach has been successfully applied to more code -- that is, >> all of Windows, and then some. >> >> Windows C/C++ is flawed here, but not in a too terrible way. >> In particular, Windows C/C++ has too many names for the same >> types, with various >> flimsy rationale, mostly "style" and "history". >> >> All you need is the following: >> >> signed and unsigned integer types that are exactly 8 bits in size >> signed and unsigned integer types that are exactly 16 bits in size >> signed and unsigned integer types that are exactly 32 bits in size >> signed and unsigned integer types that are exactly 64 bits in size >> signed and unsigned integer types that are exactly the size of a >> pointer >> >> 10 integer types total, named something like: >> INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, >> size_t or UINT_PTR, ptrdiff_t or INT_PTR >> >> The types "int" and "long" and unsigned thereof NEVER changed size. >> Where people were using them for pointer sized things, you would >> do a simple transform to port to 64 bit: >> int => INT => INT_PTR >> unsigned => UINT => UINT_PTR >> DWORD => DWORD_PTR >> >> convert to the upper case types if not there, and append "_PTR" >> >> The existing types size_t and ptrdiff_t did change size. >> If someone really needed 32 bit types there, you'd have to >> change your code. >> >> Windows has more than that for historical and stylistics reasons >> -- upper case types, >> lowercase types, types that "favor" being unsigned int or >> unsigned long. >> >> Some of it is C's fault -- the "short" and "long" stuff seems all >> unnecessary. >> >> C 9x adds in "fast" and "small" types >> types that are the smallest type that is at least a certain >> size, I think >> types that are the fastest type that are at least a certain >> size, I think >> the idea here being that if 64 bit integers are "faster" than >> 32 bit integers, then "fast32" might be 64 bits >> >> In reality, I think the 10 types are confusing enough, but >> necessary, C9x multiplies out >> beyond necessity. Yeah, obviously, they seem like maybe you >> might want them, but >> it's just too many times imho. Imho 8, 16, and 32 bit integers >> must remain efficient >> to use on all forseeable processors, since tons of code uses >> them, and people should not >> will not be pushed to widen everything across the board. Yeah, >> 64K and 4GB limits are >> mostly stupid these days and they very often should be widened, >> but folks can do that >> "slowly" on their own, managing compatibilit themselves -- like >> where binary file i/o is used. >> >> Why has this been so hard in Modula-3? >> >> Is it that "Word" is widely used and has been pointer sized? >> Or that INTEGER has been widely used and sometimes assumed to be >> pointer sized? >> >> Is it that Sparc64 (?) and 64 bit Alpha have existed for a long >> time but >> weren't done right and there is some legacy we are stuck with?? >> >> Do "subrange" types make it all confusing? >> >> Or merely the assignment rules among the non subrange integer >> types? >> >> I have not paid particularly close attention; it just has always >> surprised me >> that it was difficult to work out what to do. >> >> I guess it is all moot now, the issues have been worked out and >> the feature is there. Good. >> >> I am skeptical that the name "LONGINT" is good. I am skeptical >> that the slightly >> abstracted C names "short", "int", "long" are a useful abstraction. >> I think you really want the 10 base types I first listed. >> >> btw, even the types that are same size as a pointer are overused >> in C/C++. >> You don't need them for as much pointer arithmetic as people use. >> You can use "char*" for that. >> They are useful for array indices though, the result of wcslen, >> sizeof(), etc. >> >> File sizes should always be UINT64.. >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From jayk123 at hotmail.com Sat Aug 11 19:06:57 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:06:57 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: I can build the compiler, but, youch, can't build m3core\long.m3: "..\src\word\Long.m3", line 11: Unknown type of size other than dword in movOp The x86 back end needs work..I'll see if I can't just provide this stuff in C and avoid understanding the backend much.. - Jay> From: hosking at cs.purdue.edu> Date: Wed, 8 Aug 2007 08:39:34 -0400> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > Make sure to start with clean build directories and clean before > building with the bootstrapped compiler...> > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote:> > > Amended bootstrap instructions:> >> > Compiler and runtime extensions to support LONGINT type.> > > > Bootstrapping instructions: build and ship packages in the > > following order> > > > m3cc> > m3middle> > m3linker> > m3front> > m3quake> > cm3> > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> > > > Use this new compiler to build and ship the new system:> > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> > cd cm3/scripts> > ./do-cm3-std.sh realclean> > > ./do-cm3-std.sh buildship> > > > If this is successful then move the new compiler to BINDIR:> > > > mv $CM3 INSTALL_DIR/bin/cm3> >> > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: hosking at birch. 07/08/08 05:50:13> >>> >> Modified files:> >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html> >> for.html index.html m3.html m3index.html> >> numbers.html ordinal.html subtypes.html> >> typeops.html word-intf.html> >> cm3/m3-db/smalldb/src/: OSSupport.m3> >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3> >> SocketPosix.m3> >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3> >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c> >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3> >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3> >> cm3/m3-libs/m3core/src/thread/: m3makefile> >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3> >> Utypes.i3> >> m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/word/: m3makefile> >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> cm3/m3-sys/m3front/src/: m3makefile> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3> >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3> >> Dec.m3 First.m3 Floatt.m3> >> Floor.m3 Inc.m3 Last.m3> >> Max.m3 New.m3 Number.m3> >> Ord.m3 Round.m3 Subarray.m3> >> Trunc.m3 Val.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3> >> m3makefile> >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3> >> WordInsert.m3 WordModule.m3> >> WordNot.m3 WordOr.m3> >> WordRotate.m3 WordShift.m3> >> WordXor.m3> >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3> >> CastExpr.m3 CheckExpr.m3> >> CompareExpr.m3 DivExpr.m3> >> EqualExpr.m3 Expr.m3 ExprParse.m3> >> InExpr.m3 IntegerExpr.i3> >> IntegerExpr.m3 ModExpr.m3> >> MultiplyExpr.m3 NegateExpr.m3> >> ReelExpr.i3 ReelExpr.m3> >> SetExpr.m3 SubscriptExpr.m3> >> SubtractExpr.m3> >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3> >> Marker.m3 Scanner.m3 TipeDesc.i3> >> TipeDesc.m3 Token.i3 Token.m3> >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3> >> ForStmt.m3 TryFinStmt.m3> >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3> >> OpenArrayType.m3 SubrangeType.m3> >> Type.i3 Type.m3> >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3> >> Module.m3 Variable.m3> >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3> >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3> >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3> >> TWord.i3 TWord.m3 Target.i3 Target.m3> >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3> >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3> >> M3Lexer.m3 M3Type.i3 M3Type.m3> >> cm3/m3-tools/m3browser/src/: Main.m3> >> Added files:> >> cm3/doc/reference/: m3logo.gif> >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3> >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3> >> LongDivide.i3 LongDivide.m3> >> LongExtract.i3> >> LongExtract.m3 LongGE.i3> >> LongGE.m3 LongGT.i3> >> LongGT.m3 LongInsert.i3> >> LongInsert.m3 LongLE.i3> >> LongLE.m3 LongLT.i3> >> LongLT.m3 LongMinus.i3> >> LongMinus.m3 LongMod.i3> >> LongMod.m3 LongModule.i3> >> LongModule.m3 LongNot.i3> >> LongNot.m3 LongOr.i3> >> LongOr.m3 LongPlus.i3> >> LongPlus.m3 LongRotate.i3> >> LongRotate.m3 LongShift.i3> >> LongShift.m3 LongTimes.i3> >> LongTimes.m3 LongXor.i3> >> LongXor.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3> >>> >> Log message:> >> Compiler and runtime extensions to support LONGINT type.> >> > >> Bootstrapping instructions: build and ship packages in the > >> following order> >> > >> m3middle> >> m3linker> >> m3front> >> m3quake> >> cm3> >> > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> >> > >> Use this new compiler to build and ship the new system:> >> > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> >> cd cm3/scripts> >> ./do-cm3-std.sh buildship> >> > >> If this is successful then move the new compiler to BINDIR:> >> > >> mv $CM3 INSTALL_DIR/bin/cm3> >> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 19:14:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:14:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <078AEEB2-F545-43ED-B01D-2783D318C4F9@cs.purdue.edu> Did you rebuild the backend? I have built this on Darwin x86 and Linux x86 without problems. On Aug 11, 2007, at 1:06 PM, j k wrote: > I can build the compiler, but, youch, can't build m3core\long.m3: > > "..\src\word\Long.m3", line 11: Unknown type of size other than > dword in movOp > > The x86 back end needs work..I'll see if I can't just provide this > stuff in C and avoid understanding the backend much.. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Wed, 8 Aug 2007 08:39:34 -0400 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Make sure to start with clean build directories and clean before > > building with the bootstrapped compiler... > > > > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > > > > > Amended bootstrap instructions: > > > > > > Compiler and runtime extensions to support LONGINT type. > > > > > > Bootstrapping instructions: build and ship packages in the > > > following order > > > > > > m3cc > > > m3middle > > > m3linker > > > m3front > > > m3quake > > > cm3 > > > > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > > > > > Use this new compiler to build and ship the new system: > > > > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > > cd cm3/scripts > > > > ./do-cm3-std.sh realclean > > > > > ./do-cm3-std.sh buildship > > > > > > If this is successful then move the new compiler to BINDIR: > > > > > > mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: hosking at birch. 07/08/08 05:50:13 > > >> > > >> Modified files: > > >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html > > >> for.html index.html m3.html m3index.html > > >> numbers.html ordinal.html subtypes.html > > >> typeops.html word-intf.html > > >> cm3/m3-db/smalldb/src/: OSSupport.m3 > > >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > > >> SocketPosix.m3 > > >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > > >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > > >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > > >> cm3/m3-libs/m3core/src/thread/: m3makefile > > >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > > >> Utypes.i3 > > >> m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/word/: m3makefile > > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> cm3/m3-sys/m3front/src/: m3makefile > > >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > > >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > > >> Dec.m3 First.m3 Floatt.m3 > > >> Floor.m3 Inc.m3 Last.m3 > > >> Max.m3 New.m3 Number.m3 > > >> Ord.m3 Round.m3 Subarray.m3 > > >> Trunc.m3 Val.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > > >> m3makefile > > >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > > >> WordInsert.m3 WordModule.m3 > > >> WordNot.m3 WordOr.m3 > > >> WordRotate.m3 WordShift.m3 > > >> WordXor.m3 > > >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > > >> CastExpr.m3 CheckExpr.m3 > > >> CompareExpr.m3 DivExpr.m3 > > >> EqualExpr.m3 Expr.m3 ExprParse.m3 > > >> InExpr.m3 IntegerExpr.i3 > > >> IntegerExpr.m3 ModExpr.m3 > > >> MultiplyExpr.m3 NegateExpr.m3 > > >> ReelExpr.i3 ReelExpr.m3 > > >> SetExpr.m3 SubscriptExpr.m3 > > >> SubtractExpr.m3 > > >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > > >> Marker.m3 Scanner.m3 TipeDesc.i3 > > >> TipeDesc.m3 Token.i3 Token.m3 > > >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > > >> ForStmt.m3 TryFinStmt.m3 > > >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > > >> OpenArrayType.m3 SubrangeType.m3 > > >> Type.i3 Type.m3 > > >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > > >> Module.m3 Variable.m3 > > >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > > >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > > >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > > >> TWord.i3 TWord.m3 Target.i3 Target.m3 > > >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > > >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > > >> M3Lexer.m3 M3Type.i3 M3Type.m3 > > >> cm3/m3-tools/m3browser/src/: Main.m3 > > >> Added files: > > >> cm3/doc/reference/: m3logo.gif > > >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > > >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > > >> LongDivide.i3 LongDivide.m3 > > >> LongExtract.i3 > > >> LongExtract.m3 LongGE.i3 > > >> LongGE.m3 LongGT.i3 > > >> LongGT.m3 LongInsert.i3 > > >> LongInsert.m3 LongLE.i3 > > >> LongLE.m3 LongLT.i3 > > >> LongLT.m3 LongMinus.i3 > > >> LongMinus.m3 LongMod.i3 > > >> LongMod.m3 LongModule.i3 > > >> LongModule.m3 LongNot.i3 > > >> LongNot.m3 LongOr.i3 > > >> LongOr.m3 LongPlus.i3 > > >> LongPlus.m3 LongRotate.i3 > > >> LongRotate.m3 LongShift.i3 > > >> LongShift.m3 LongTimes.i3 > > >> LongTimes.m3 LongXor.i3 > > >> LongXor.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > >> > > >> Log message: > > >> Compiler and runtime extensions to support LONGINT type. > > >> > > >> Bootstrapping instructions: build and ship packages in the > > >> following order > > >> > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > >> > > >> Use this new compiler to build and ship the new system: > > >> > > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > >> cd cm3/scripts > > >> ./do-cm3-std.sh buildship > > >> > > >> If this is successful then move the new compiler to BINDIR: > > >> > > >> mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > > > Recharge--play some free games. Win cool prizes too! Play It! From hosking at cs.purdue.edu Sat Aug 11 19:19:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:19:56 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details References: <200708111715.l7BHFAJn017822@hermes50.mail.cornell.edu> Message-ID: Jay, your e-mails are bouncing. Begin forwarded message: > From: Mail Delivery Subsystem > Date: August 11, 2007 1:15:10 PM EDT > To: hosking at cs.purdue.edu > Subject: Returned mail: see transcript for details > > The original message was received at Sat, 11 Aug 2007 13:15:10 > -0400 (EDT) > from daemon at localhost > > ----- The following addresses had permanent fatal errors ----- > jaykrell at verizon.net > > ----- Transcript of session follows ----- > ... while talking to relay.verizon.net.: >>>> DATA > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > 550 5.1.1 jaykrell at verizon.net... User unknown > <<< 554 5.5.0 No recipients have been specified. > Reporting-MTA: dns; hermes50.mail.cornell.edu > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > Final-Recipient: RFC822; jaykrell at verizon.net > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; relay.verizon.net > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > From: Tony Hosking > Date: August 11, 2007 1:14:21 PM EDT > To: > Cc: Modula-3 developers , > > Subject: Re: [M3commit] CVS Update: cm3 > > > Did you rebuild the backend? > > I have built this on Darwin x86 and Linux x86 without problems. > > On Aug 11, 2007, at 1:06 PM, j k wrote: > >> I can build the compiler, but, youch, can't build m3core\long.m3: >> >> "..\src\word\Long.m3", line 11: Unknown type of size other than >> dword in movOp >> >> The x86 back end needs work..I'll see if I can't just provide this >> stuff in C and avoid understanding the backend much.. >> >> - Jay >> From jayk123 at hotmail.com Sat Aug 11 19:55:06 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:55:06 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:53:00 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:53:00 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Ok, other than calling it "the x86 backend", I think I'm right. I wasn't sure if it was for all x86 platforms or just Windows.How about the "non gcc" backend? I think only Windows uses it and no other platform.I can get much further still having fixed BuildStandalone functionality in m3-sys\cminstall\src\config\NT386. I broke it a few months ago. I got as far as m3ui and something with RTHeapDep, I think the problem there is the interface got deleted between the last binary distribution and now. I'll dig a bit more.After fixing BuildStandalone, tried again with the inline Long.m3 and got the same errors so I put back my C implementation -- I am NOT sure it is right, either in calling convention or in implementing the shift/rotate/extract/insert stuff correctly.Now cm3 -ship works on m3core.dll as well but that's a different point. - JayFrom: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Sat, 11 Aug 2007 17:55:06 +0000Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> New home for Mom, no cleanup required. All starts here. _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:54:55 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:54:55 +0000 Subject: [M3devel] missing commits Message-ID: fyi, I'm not seeing my commits, probably my fault with my screwy-for-months-now mail configuration. I do intend to fix it soon... - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 21:03:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 15:03:32 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details In-Reply-To: References: Message-ID: Ah, yes the Windows (non-gcc) x86 backed will certainly need fixing to handle 64-bit integers. I had forgotten that Windows does not use the gcc-based backend. The principal differences can probably be figured out by looking at how Long.m3 gets compiled. Take a look at the changes to M3CG_Ops.i3 to get a sense for what changes were made to the interface between the middle and back ends. On Aug 11, 2007, at 2:53 PM, j k wrote: > Ok, other than calling it "the x86 backend", I think I'm right. I > wasn't sure if it was for all x86 platforms or just Windows. > > How about the "non gcc" backend? I think only Windows uses it and > no other platform. > > I can get much further still having fixed BuildStandalone > functionality in m3-sys\cminstall\src\config\NT386. I broke it a > few months ago. I got as far as m3ui and something with RTHeapDep, > I think the problem there is the interface got deleted between the > last binary distribution and now. I'll dig a bit more. > > After fixing BuildStandalone, tried again with the inline Long.m3 > and got the same errors so I put back my C implementation -- I am > NOT sure it is right, either in calling convention or in > implementing the shift/rotate/extract/insert stuff correctly. > > Now cm3 -ship works on m3core.dll as well but that's a different > point. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sat, 11 Aug 2007 17:55:06 +0000 > Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details > > Yeah sorry I have to fix that forwarding, been broken for months > but almost have it fixed. > jayk123 at hotmail.com works. > > Hm. Geez I don't know. I guess I should stop submitting for now. > Let me figure more stuff out. > > I built cm3.exe and am running it. I had more errors before fixing > the Windows clearenv.cmd, I submitted a fix for it -- it was > clearing %cm3%. > > I have to track down where the gcc vs. no gcc decision is made. > Maybe it is only x86 Windows that uses this code, not all x86 > platforms? > > I can get further with my changes but then I crash and I probably > won't make much more progress today. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 13:19:56 -0400 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Fwd: Returned mail: see transcript for details > > > > Jay, your e-mails are bouncing. > > > > Begin forwarded message: > > > > > From: Mail Delivery Subsystem > > > Date: August 11, 2007 1:15:10 PM EDT > > > To: hosking at cs.purdue.edu > > > Subject: Returned mail: see transcript for details > > > > > > The original message was received at Sat, 11 Aug 2007 13:15:10 > > > -0400 (EDT) > > > from daemon at localhost > > > > > > ----- The following addresses had permanent fatal errors ----- > > > jaykrell at verizon.net > > > > > > ----- Transcript of session follows ----- > > > ... while talking to relay.verizon.net.: > > >>>> DATA > > > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > > > 550 5.1.1 jaykrell at verizon.net... User unknown > > > <<< 554 5.5.0 No recipients have been specified. > > > Reporting-MTA: dns; hermes50.mail.cornell.edu > > > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > Final-Recipient: RFC822; jaykrell at verizon.net > > > Action: failed > > > Status: 5.1.1 > > > Remote-MTA: DNS; relay.verizon.net > > > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > From: Tony Hosking > > > Date: August 11, 2007 1:14:21 PM EDT > > > To: > > > Cc: Modula-3 developers , > > > > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Did you rebuild the backend? > > > > > > I have built this on Darwin x86 and Linux x86 without problems. > > > > > > On Aug 11, 2007, at 1:06 PM, j k wrote: > > > > > >> I can build the compiler, but, youch, can't build m3core\long.m3: > > >> > > >> "..\src\word\Long.m3", line 11: Unknown type of size other than > > >> dword in movOp > > >> > > >> The x86 back end needs work..I'll see if I can't just provide > this > > >> stuff in C and avoid understanding the backend much.. > > >> > > >> - Jay > > >> > > > > > New home for Mom, no cleanup required. All starts here. > Messenger Caf? ? open for fun 24/7. Hot games, cool activities > served daily. Visit now. From darko at darko.org Sat Aug 11 22:15:22 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 22:15:22 +0200 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> The last commit I got was beginning of April. I think there might be a wider problem. On 11/08/2007, at 8:54 PM, j k wrote: > fyi, I'm not seeing my commits, probably my fault with my screwy- > for-months-now mail configuration. I do intend to fix it soon... > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 01:01:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 19:01:40 -0400 Subject: [M3devel] missing commits In-Reply-To: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> References: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> Message-ID: <7B496A29-42B3-499E-9CF9-5AF651C72075@cs.purdue.edu> I know there was a problem with the mailing list and I ended up re- subscribing using my CVS username from the elegosoft web-site. It seems that commits via CVS accounts pipe to the mailing list, but you need to be subscribed with that id. On Aug 11, 2007, at 4:15 PM, Darko wrote: > The last commit I got was beginning of April. I think there might > be a wider problem. > > > On 11/08/2007, at 8:54 PM, j k wrote: > >> fyi, I'm not seeing my commits, probably my fault with my screwy- >> for-months-now mail configuration. I do intend to fix it soon... >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From rodney.bates at wichita.edu Sun Aug 12 02:44:18 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 11 Aug 2007 19:44:18 -0500 Subject: [M3devel] Latex M3 language definition Message-ID: <46BE57E2.90307@wichita.edu> I propose to fix up m3-defn-complete.tex as much as possible before adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can have an up to date-PM3-definition. The .tex I found does not have any face tags for the code samples in the running text (as does the .html), nor does it have anything denoting the hyperlinks in it. I guess they will have to be inserted manually. This would quite a bit of stuff to try to merge with the CM3 changes, if they were to get done first. Other than that, the .tex looks like the actual content is very close to identical to the .html one-page form. I did a careful parallel reading, (as close as mere mortals could have much hope of doing). So the .tex is not exactly the predecessor that the .html was derived from. I have done some net searching trying to find another .tex, but to no avail, so far. It does look like latex2html will do what is needed, particularly allowing tex tags that will turn into hyperlinks in html and get ignored by latex for a printed version. It also appears to have something for optionally generating multi-page html as well. I think there is a successor to it, but haven't checked that out yet. -- ------------------------------------------------------------- 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 Sun Aug 12 04:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 22:05:28 -0400 Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: I'm halfwa done on some of that, so hang on a mo'. On Aug 11, 2007, at 8:44 PM, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. > > Other than that, the .tex looks like the actual content is very close > to identical to the .html one-page form. I did a careful parallel > reading, (as close as mere mortals could have much hope of doing). > So the .tex is not exactly the predecessor that the .html was derived > from. I have done some net searching trying to find another .tex, > but to no avail, so far. > > It does look like latex2html will do what is needed, particularly > allowing tex tags that will turn into hyperlinks in html and get > ignored by latex for a printed version. It also appears to have > something for optionally generating multi-page html as well. I think > there is a successor to it, but haven't checked that out yet. > > -- > ------------------------------------------------------------- > 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 lemming at henning-thielemann.de Sun Aug 12 06:52:29 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 12 Aug 2007 06:52:29 +0200 (MEST) Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: On Sat, 11 Aug 2007, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. I also remember that the Module-3 definition states that only one exception per EXCEPTION keyword can be defined, which seems to be relaxed in cm3 and pm3. From derick_eddington at yahoo.com Sun Aug 12 06:49:23 2007 From: derick_eddington at yahoo.com (Derick Eddington) Date: Sat, 11 Aug 2007 21:49:23 -0700 (PDT) Subject: [M3devel] unsubcribe Message-ID: <982895.80961.qm@web58713.mail.re1.yahoo.com> ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From jayk123 at hotmail.com Sun Aug 12 07:24:06 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 05:24:06 +0000 Subject: [M3devel] missing commits Message-ID: I am getting Tony's .tex commits, but didn't see mine.I say this half to cover my butt -- I made some commits.If I'm not seeing them, others maybe aren't either.I added a C version of Long.m3 for Win32.Not sure it is right, in a few ways. How it uses the stack. If it shifts and all by the right amounts? (n or 64 - n?) It definitely lets the build progress further. Surely it isn't ideal -- the C code actually generates calls out to the C runtime even, under the covers, so what was meant to be inlined is a two deep call tree! (The compiler generates the calls.)I fixed cminstall/src/config/NT386 so BuildStandalone works.I fixed scripts/win/clearenv.cmd so the user can set CM3 as per Tony's bootstrap instructions.Maybe others, don't recall.Nothing large.I figure I'll remove a bunch of extra semicolons in some C code.Any thoughts on the #ifdef __cplusplus extern "C" in C code? - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 19:01:40 -0400> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > I know there was a problem with the mailing list and I ended up re- > subscribing using my CVS username from the elegosoft web-site. It > seems that commits via CVS accounts pipe to the mailing list, but you > need to be subscribed with that id.> > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > > The last commit I got was beginning of April. I think there might > > be a wider problem.> >> >> > On 11/08/2007, at 8:54 PM, j k wrote:> >> >> fyi, I'm not seeing my commits, probably my fault with my screwy- > >> for-months-now mail configuration. I do intend to fix it soon...> >>> >> - Jay> >>> >> Recharge--play some free games. Win cool prizes too! Play It!> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 10:16:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 04:16:22 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <389194AD-D205-47E0-808A-E6BBC15A2CA3@cs.purdue.edu> Why do you need a C version of Long.m3 for Win32? These operations are built into the front-end, making use of backend functionality. On Aug 12, 2007, at 1:24 AM, j k wrote: > I am getting Tony's .tex commits, but didn't see mine. > I say this half to cover my butt -- I made some commits. > If I'm not seeing them, others maybe aren't either. > > I added a C version of Long.m3 for Win32. > Not sure it is right, in a few ways. > How it uses the stack. > If it shifts and all by the right amounts? (n or 64 - n?) > It definitely lets the build progress further. > Surely it isn't ideal -- the C code actually generates > calls out to the C runtime even, under the covers, so what > was meant to be inlined is a two deep call tree! > (The compiler generates the calls.) > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > I fixed scripts/win/clearenv.cmd so the user > can set CM3 as per Tony's bootstrap instructions. > > Maybe others, don't recall. > Nothing large. > > I figure I'll remove a bunch of extra semicolons in some C code. > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > To: darko at darko.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > I know there was a problem with the mailing list and I ended up re- > > subscribing using my CVS username from the elegosoft web-site. It > > seems that commits via CVS accounts pipe to the mailing list, but > you > > need to be subscribed with that id. > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > The last commit I got was beginning of April. I think there might > > > be a wider problem. > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > >> fyi, I'm not seeing my commits, probably my fault with my screwy- > > >> for-months-now mail configuration. I do intend to fix it soon... > > >> > > >> - Jay > > >> > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Sun Aug 12 14:39:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 12 Aug 2007 14:39:34 +0200 Subject: [M3devel] Error building cvshead m3gdb od x86_64 Linux Message-ID: <1186922374.9120.24.camel@faramir.m3w.org> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/i386-linux-nat.c In file included from ../../gdb/gdb/i386-linux-nat.c:65: ../../gdb/gdb/gregset.h:63: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?gdb_fpxregset_t? ../../gdb/gdb/gregset.h:65: error: expected ?)? before ?*? token ../../gdb/gdb/gregset.h:66: error: expected ?)? before ?*? token -- Dragi?a Duri? From jayk123 at hotmail.com Sun Aug 12 21:20:07 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:20:07 +0000 Subject: [M3devel] missing commits Message-ID: Because it doesn't work currently. This was easier but I agree not ideal. - Jay> From: hosking at cs.purdue.edu> Date: Sun, 12 Aug 2007 04:16:22 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > Why do you need a C version of Long.m3 for Win32? These operations > are built into the front-end, making use of backend functionality.> > On Aug 12, 2007, at 1:24 AM, j k wrote:> > > I am getting Tony's .tex commits, but didn't see mine.> > I say this half to cover my butt -- I made some commits.> > If I'm not seeing them, others maybe aren't either.> >> > I added a C version of Long.m3 for Win32.> > Not sure it is right, in a few ways.> > How it uses the stack.> > If it shifts and all by the right amounts? (n or 64 - n?)> > It definitely lets the build progress further.> > Surely it isn't ideal -- the C code actually generates> > calls out to the C runtime even, under the covers, so what> > was meant to be inlined is a two deep call tree!> > (The compiler generates the calls.)> >> > I fixed cminstall/src/config/NT386 so BuildStandalone works.> >> > I fixed scripts/win/clearenv.cmd so the user> > can set CM3 as per Tony's bootstrap instructions.> >> > Maybe others, don't recall.> > Nothing large.> >> > I figure I'll remove a bunch of extra semicolons in some C code.> >> > Any thoughts on the #ifdef __cplusplus extern "C" in C code?> >> > - Jay> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 11 Aug 2007 19:01:40 -0400> > > To: darko at darko.org> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] missing commits> > >> > > I know there was a problem with the mailing list and I ended up re-> > > subscribing using my CVS username from the elegosoft web-site. It> > > seems that commits via CVS accounts pipe to the mailing list, but > > you> > > need to be subscribed with that id.> > >> > > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > >> > > > The last commit I got was beginning of April. I think there might> > > > be a wider problem.> > > >> > > >> > > > On 11/08/2007, at 8:54 PM, j k wrote:> > > >> > > >> fyi, I'm not seeing my commits, probably my fault with my screwy-> > > >> for-months-now mail configuration. I do intend to fix it soon...> > > >>> > > >> - Jay> > > >>> > > >> Recharge--play some free games. Win cool prizes too! Play It!> > > >> > >> >> > See what you?re getting into?before you go there See it!> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:27:05 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:27:05 +0000 Subject: [M3devel] new Win32 build from current source Message-ID: Can folks try this? Make it available on the web page?There hasn't been a win32 release for longer than other platforms.I can build "core" and "std" if folks want.These files are directly output from scripts\win\make-dist.cmd. It has the support for "core" and "std", commented out. If folks prefer, tar.gz, .zip, and self extracting .zip are possible; .bz2 is smallest. Perhaps a version number should be in the .tar path structure? The install instructions are like (no cminstall, replaced by using vcvars32.bat which lets one CM3 install move among different tools, debatable which is better) cd /d c:\ optionally rmdir /q/s cm3 tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 run the usual vcvars32.bat or whatever (or use the start menu link that Visual C++ setup creates) set PATH=c:\cm3\bin;%PATH% set LIB=c:\cm3\lib;%lib% optionally, a good test: cd \scripts\win .\do-pkg-std realclean .\do-pkg-std buildship I have not tested the longint stuff and it likely doesn't work yet. The files are in ~jkrell on m3.elegosoft.com: C:\>ssh jkrell at m3.elegosoft.com find . ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 Remember you will need http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 or I could build it with an older toolset if folks want. Thanks, - Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 21:32:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:32:02 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <14E40138-3008-42B2-AD21-C6AA96DFFA12@cs.purdue.edu> Not only not ideal, but deferring the pain. We need to be able to compile 64-bit operations on 32-bit machines and that means updating the backend. Long.m3 is a good test-case for all the ops that you need for LONGINT support. On Aug 12, 2007, at 3:20 PM, j k wrote: > Because it doesn't work currently. This was easier but I agree not > ideal. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sun, 12 Aug 2007 04:16:22 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > Why do you need a C version of Long.m3 for Win32? These operations > > are built into the front-end, making use of backend functionality. > > > > On Aug 12, 2007, at 1:24 AM, j k wrote: > > > > > I am getting Tony's .tex commits, but didn't see mine. > > > I say this half to cover my butt -- I made some commits. > > > If I'm not seeing them, others maybe aren't either. > > > > > > I added a C version of Long.m3 for Win32. > > > Not sure it is right, in a few ways. > > > How it uses the stack. > > > If it shifts and all by the right amounts? (n or 64 - n?) > > > It definitely lets the build progress further. > > > Surely it isn't ideal -- the C code actually generates > > > calls out to the C runtime even, under the covers, so what > > > was meant to be inlined is a two deep call tree! > > > (The compiler generates the calls.) > > > > > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > > > > > I fixed scripts/win/clearenv.cmd so the user > > > can set CM3 as per Tony's bootstrap instructions. > > > > > > Maybe others, don't recall. > > > Nothing large. > > > > > > I figure I'll remove a bunch of extra semicolons in some C code. > > > > > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > > > To: darko at darko.org > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] missing commits > > > > > > > > I know there was a problem with the mailing list and I ended > up re- > > > > subscribing using my CVS username from the elegosoft web- > site. It > > > > seems that commits via CVS accounts pipe to the mailing list, > but > > > you > > > > need to be subscribed with that id. > > > > > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > > > > > The last commit I got was beginning of April. I think there > might > > > > > be a wider problem. > > > > > > > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > > > > > >> fyi, I'm not seeing my commits, probably my fault with my > screwy- > > > > >> for-months-now mail configuration. I do intend to fix it > soon... > > > > >> > > > > >> - Jay > > > > >> > > > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > > > > > > > > > See what you?re getting into?before you go there See it! > > > > > New home for Mom, no cleanup required. All starts here. From hosking at cs.purdue.edu Sun Aug 12 21:34:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:34:30 -0400 Subject: [M3devel] new Win32 build from current source In-Reply-To: References: Message-ID: <83F32D11-E8ED-4CD8-B400-F3DDE7795D56@cs.purdue.edu> LONGINT will need work on the native x86 backend. Should not be too hard, given how little needed to change for the gcc-based backend to handle LONGINT. [PS I have a couple of fixes to LONGINT that I am working on in the front-end compiler. Issues with LONGINT subranges and their representation. I am hoping this fixes the bug I discovered in LONGINT on PPC_DARWIN w.r.to off_t in file stat structs.] On Aug 12, 2007, at 3:27 PM, j k wrote: > Can folks try this? Make it available on the web page? > There hasn't been a win32 release for longer than other platforms. > I can build "core" and "std" if folks want. > These files are directly output from scripts\win\make-dist.cmd. > It has the support for "core" and "std", commented out. > If folks prefer, tar.gz, .zip, and self extracting .zip are > possible; .bz2 is smallest. > Perhaps a version number should be in the .tar path structure? > > The install instructions are like (no cminstall, replaced by using > vcvars32.bat which lets one CM3 install move among different tools, > debatable which is better) > > cd /d c:\ > optionally rmdir /q/s cm3 > tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > run the usual vcvars32.bat or whatever (or use the start menu link > that Visual C++ setup creates) > set PATH=c:\cm3\bin;%PATH% > set LIB=c:\cm3\lib;%lib% > > optionally, a good test: > cd \scripts\win > .\do-pkg-std realclean > .\do-pkg-std buildship > > I have not tested the longint stuff and it likely doesn't work yet. > > The files are in ~jkrell on m3.elegosoft.com: > C:\>ssh jkrell at m3.elegosoft.com find . > > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Remember you will need > http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE- > A3F9-4C13-9C99-220B62A191EE > or http://www.microsoft.com/downloads/details.aspx? > FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 > > or I could build it with an older toolset if folks want. > > Thanks, > - Jay > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Sun Aug 12 21:39:31 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:39:31 +0000 Subject: [M3devel] Some random notes on building/running Modula-3 on Windows (XP). Message-ID: Some of this is redundant -- i.e. has long been working. Some of it is specific to my configuration and habits. You are expected to recognize that. :) I am running Windows XP and currently using Visual C++ 8.0, though many versions of NT and VC should work. Some work has been put into ensuring multiple versions of VC work. Checkout the latest source. Really the latest. (at least of August 12 11am Pacific time). Download and extract the "latest" binary distribution, it is old but ok: cm3-min-WIN32-NT386-5.2.6.tar.bz2 Or maybe it was .gz, I always change them to save space. For me it is at C:\net\modula3\cm3-min-WIN32-NT386-5.2.6.tar.bz2 I install to the default c:\cm3. Prior to running cminstall, mkdir c:\cm3\t. Whenever cminstall asks for a path to a directory, just say c:\cm3\t. (It insists on an existing path, but with my configuration file, which is generic and checked in, none of them are used.) None of these paths matters if you do things this way. After running cminstall, you may rmdir the empty c:\cm3\t. Replace c:\cm3\bin\cm3.cfg with the latest source's cm3\m3-sys\cminstall\src\config\NT386. No edits are necessary. Or, if doing this repeatedly, I have it like so: cm3-min-WIN32-NT386-5.2.6.tar.bz2 is extracted to \net\modula3\cm3-min-WIN32-NT386-5.2.6\t and modified: delete bin\cm3.cfg delete bin\cm3.cfg--default and then to restore just: xcopy /fiveryh \net\modula3\cm3-min-WIN32-NT386-5.2.6\t \cm3 You need /h for hidden because tar will hide files like .M3EXPORTS that start with a dot. t for temp Setup your Visual C++ environment (%PATH%, %LIB%, %INCLUD%) by running the usual vcvars32.bat. For me this is running \env\cm3.vc80.bat (also have \env\cm3.vc20.bat, 40, 41, 42, 50, 60, 70, 71) set LIB=c:\cm3\lib;%LIB% set PATH=c:\cm3\bin;%PATH% Given the source tree at \dev2\cm3.2 I use \dev2 since Unix "takes" \dev. cm3.2 is because cm3 is an older tree I need to get the diffs out of and delete. These instructions are based on Tony's and very similar. Mainly that Windows does not use gcc. cd \dev2\cm3.2\scripts\win @rem make sure %CM3% is clear, in case of running through this stuff multiple times. set CM3= .\do-pkg realclean import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 .\do-pkg buildship import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 set CM3=C:\dev2\cm3.2\m3-sys\cm3\NT386\cm3.exe .\do-cm3-std realclean .\do-cm3-std buildship .\install-cm3-compiler upgrade Alternatively: extract/install/configure latest distribution as above checkout latest source cd scripts\win .\make-dist This gives you: cm3-min-WIN32-NT386-d5.3.2.tar.bz2 cm3-min-WIN32-NT386-d5.3.2-symbols.tar.bz2 buried in temp. I have not tested the new LONGINT functionality and there's a good chance it doesn't work yet. Various GUI apps start up ok. formsedit starts up and show gui. juno starts and shows gui, but crashes easily: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x5aaf8f8 0xf4fc2c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x5aafd54 0xf4db55 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... vorun brings up gui visobliq brings up gui not sure how to exit, had to kill it shownew brings up gui showheap brings up gui showthread brings up gui - Jay _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Mon Aug 13 21:44:47 2007 From: stsp at elego.de (Stefan Sperling) Date: Mon, 13 Aug 2007 21:44:47 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813143915.71BE510D4363@birch.elegosoft.com> References: <20070813143915.71BE510D4363@birch.elegosoft.com> Message-ID: <20070813194447.GE1351@ted.stsp.lan> On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 07/08/13 16:39:15 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c > > Log message: > No change to the contents of these files. This is an attempt to get > the time stampof ada-lex.c to be later than that of ada-lex.l. This > will mean m3gdb will build without requiring flex to be installed. What about hacking a 'touch ada-lex.c' into the Makefile somewhere instead? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rodney.bates at wichita.edu Mon Aug 13 23:41:32 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 16:41:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813194447.GE1351@ted.stsp.lan> References: <20070813143915.71BE510D4363@birch.elegosoft.com> <20070813194447.GE1351@ted.stsp.lan> Message-ID: <46C0D00C.5030903@wichita.edu> This works when I do a complete fresh cvs checkout on a different machine and build, with flex disabled. The checked-out files on the second machine show the times I edited my originals on the first machine, before committing. But when, on yet a 3rd machine, I do a cvs update, both files show identical times, the time that the update happened. So something more is needed. Is there a way to get cvs to give updated files the time they have in the repository, instead of when updated? If anybody ever actually did change ada-lex.l, a touch ada-lex.c in the makefile would be wrong. After what I did, people who do an update now may go from building fine (since they got the files initially from a checkout, which gives the right time ordering), to failing. Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > >>CVSROOT: /usr/cvs >>Changes by: rodney at birch. 07/08/13 16:39:15 >> >>Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c >> >>Log message: >> No change to the contents of these files. This is an attempt to get >> the time stampof ada-lex.c to be later than that of ada-lex.l. This >> will mean m3gdb will build without requiring flex to be installed. > > > What about hacking a 'touch ada-lex.c' into the Makefile somewhere > instead? > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:11:44 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:11:44 -0500 Subject: [M3devel] A note on bootstrapping cm3 Message-ID: <46C0D720.90202@wichita.edu> If you have not rebootstrapped cm3 in a while, you may have, in your cm3.cfg, something similar to: GCWRAPFLAGS = "-Wl,--wrap,adjtime,--wrap,getdirentries,--wrap,readv,--wrap,utimes,--wrap,wait3" To build with recent cm3 compilers, this has to change to: GCWRAPFLAGS = "" The immediate symptom of this problem is link failures during building, with messages similar to undefined reference to `__wrap_utimes' -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:14:41 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:14:41 -0500 Subject: [M3devel] A note on building m3gdb Message-ID: <46C0D7D1.3000009@wichita.edu> If you don't have a working flex installed, you may get a failure trying to build m3gdb, complaining about not being able to regenerate ada-lex.c. If this happens, try doing, in the cm3 directory: touch m3-sys/m3gdb/gdb/gdb/ada-lex.c and rebuilding. -- ------------------------------------------------------------- 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 Tue Aug 14 09:43:55 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Aug 2007 09:43:55 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> On Tue, August 14, 2007 05:55, Alex Bochannek wrote: > Olaf, > > "Olaf Wagner" writes: > >> I would be surprised if that would be all; supporting other installation >> locations by the simple build scripts has really not been a target >> until now. Improvements are always welcome though, so if you have >> patches that make this abstraction they're sure to get included. > > I don't really know my way around the CM3 install scripts very well, but > I am happy to have a look and see what I can come up with. > >> cm3cg is the standard GNU compiler backend, so it may need some >> (ever increasing) infrastructure (i.e. other GNU libraries). We should >> either declare this as an explicit dependency (i.e. installation >> prerequisite) or include it in our installation archives. Probably >> it hasn't been missing for anybody else using M3 so far, because >> gcc was always installed before. > > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. Could/should I use > EZM3 to bootstrap CM3? Sounds like a good idea; we should probably add --disable-nls to our gcc configuration. I don't think it will be easy to bootstrap CM3 with EZM3 (though it should be possible); there will probably be some subtle dependencies one tends to overlook. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 16 09:03:36 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 09:03:36 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> Message-ID: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 07:37, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Sounds like a good idea; we should probably add --disable-nls to >> our gcc configuration. > > If you want to build a SOLgnu installation archive, I would be happy to > test it. > > I have been looking at building CM3 on a recent RHEL-like Linux > distribution. It seems that for the 5.4.0 release, it will build and > ship if the two known issues are taken care of (the adm/ipc.h and the > LD_POINTER_GUARD). > > However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 > installation archive seems to not be possible anymore. I followed the > email exchanges with Tony Hosking's suggested build steps and also made > the PTHREAD and GC related changes necessary to cm3.cfg. After numerous > errors due to what I think are the LONGINT changes, I gave up. I don't > really need these changes, but it looks like it might be time for > another release soon. Sure, as soon as the LONGINT changes have settled, we'll provide some new installation archives. Stefan, could you add the --disable-nls to the gcc configuration and try to build a SOLgnu archive? Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Thu Aug 16 12:22:25 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:22:25 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: <20070816102225.GA25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? Current head, 5.4, or both? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 12:59:22 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:59:22 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816102225.GA25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> Message-ID: <20070816105922.GB25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > > Stefan, could you add the --disable-nls to the gcc configuration and > > try to build a SOLgnu archive? > > Current head, 5.4, or both? Wait a minute... as far as I can tell we already build it with --disable-nls in all cases. Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk has the same): % configure the sources if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "--with-gnu-ld=yes", "&& echo \"done\" > " & done) else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--target=" & GNU_platform (M3CC_TARGET), "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end end -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Thu Aug 16 14:54:34 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 14:54:34 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816105922.GB25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> Message-ID: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 12:59, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: >> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: >> > Stefan, could you add the --disable-nls to the gcc configuration and >> > try to build a SOLgnu archive? >> >> Current head, 5.4, or both? Both :) > Wait a minute... as far as I can tell we already build it > with --disable-nls in all cases. > > Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk > has the same): > > % configure the sources > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "--with-gnu-ld=yes", > "&& echo \"done\" > " & done) > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--target=" & GNU_platform (M3CC_TARGET), > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > end Then I don't understand why the version Alex Bochannek got from our installation archives needed libiconv.so.2. Any idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Aug 16 15:42:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:42:53 -0400 Subject: [M3devel] Windows Message-ID: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> With the current native Windows backend (m3back) blindly assuming (without even checking!) that all integer operations are 32-bit, I wonder if anyone out there has the expertise, time, or inclination to smarten it up to handle both 32-bit and 64-bit ops. It should not be *too* hard, but I don't have the time for it now, though I would be happy to answer any questions that arise. Unfortunately, this reveals that Windows support is withering on the vine, in spite of Jay's excellent recent work. As of now, this means that Windows can only build CVS sources with the tag devel_LONGINT_start. Bridging the gap will require smartening up m3back or using the gcc-based backend. From stsp at elego.de Thu Aug 16 15:44:59 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 15:44:59 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> Message-ID: <20070816134458.GD25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 02:54:34PM +0200, Olaf Wagner wrote: > Then I don't understand why the version Alex Bochannek got from > our installation archives needed libiconv.so.2. Any idea? Because m3-sys/m3cc/gcc/gcc/configure.ac depends on it unconditionally. The following is in global scope: AM_ICONV # Until we have in-tree GNU iconv: LIBICONV_DEP= AC_SUBST(LIBICONV_DEP) So I guess the configure script always picks up libiconv if it is present. I'll try to remove the check for libiconv to see if the backend builds without it. The script even bothers to filter out possible multiple occurences of -liconv if --enable-nls is passed (i.e. gcc if is linked to libintl): # If LIBINTL contains LIBICONV, then clear LIBICONV so we don't get # -liconv on the link line twice. case "$LIBINTL" in *$LIBICONV*) LIBICONV= ;; esac The non-iconv case is clearly not intended by the authors of configure.ac... Also, I just checked the cm3cg binary on FreeBSD, it also depends on libiconv, which is not in the base system on FreeBSD either: % ldd /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg: libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28474000) libc.so.6 => /lib/libc.so.6 (0x28561000) -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 15:34:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:34:51 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: On Aug 16, 2007, at 3:03 AM, Olaf Wagner wrote: > On Thu, August 16, 2007 07:37, Alex Bochannek wrote: >> "Olaf Wagner" writes: >> >>> Sounds like a good idea; we should probably add --disable-nls to >>> our gcc configuration. >> >> If you want to build a SOLgnu installation archive, I would be >> happy to >> test it. I'm about to build from CVS head for SOLgnu today. I will place a bootstrap compiler (front-end and back-end) on my ftp site in the usual place. >> I have been looking at building CM3 on a recent RHEL-like Linux >> distribution. It seems that for the 5.4.0 release, it will build and >> ship if the two known issues are taken care of (the adm/ipc.h and the >> LD_POINTER_GUARD). I don't know how these issues relate to the CVS head, but I did successfully bootstrap CVS head yesterday. The compiler pieces are in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6, files cm3cg.gz and cm3.gz. >> >> However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 >> installation archive seems to not be possible anymore. I followed the >> email exchanges with Tony Hosking's suggested build steps and also >> made >> the PTHREAD and GC related changes necessary to cm3.cfg. After >> numerous >> errors due to what I think are the LONGINT changes, I gave up. I >> don't >> really need these changes, but it looks like it might be time for >> another release soon. Indeed, to bootstrap from an *old* compiler that does not handle LONGINT, you will need to build and ship in the following order: m3cc m3middle m3linker m3front m3quake cm3 Now, using the *new* stage 1 cm3 you just built (cm3/TARGET/cm3) and clean sources you can build and ship: m3core libm3 m3middle m3linker m3front m3quake cm3 With this *new* stage 2 cm3 you should be ready to build the world. > Sure, as soon as the LONGINT changes have settled, we'll provide some > new installation archives. Getting there... We really need someone to work on the *native* x86 backend m3back to smarten it up for LONGINT ... until then truly native Win32 support will be lacking (though it should be possible to build using the gcc-based backend, presumably installed and built using CygWin?). > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? I'll put a SOLgnu bootstrap compiler built from the CVS head on my ftp site later today. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From rodney.bates at wichita.edu Thu Aug 16 18:19:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 11:19:39 -0500 Subject: [M3devel] Missing .M3EXPORTS Message-ID: <46C4791B.1080207@wichita.edu> What does the following failure mean? I run into it regularly. -------------------------------------------------------------------------------------------------- rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import_version -- import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/src/m3makefile 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/LINUXLIBC6/m3make.args Fatal Error: package build failed -------------------------------------------------------------------------------------------------- Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp site into /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library locations and -gstabs to m3-link. I did a cvs update for the whole cm3 head, then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 -build and cm3 -ship. -- ------------------------------------------------------------- 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 Thu Aug 16 18:33:20 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:33:20 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4791B.1080207@wichita.edu> References: <46C4791B.1080207@wichita.edu> Message-ID: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > What does the following failure mean? I run into it regularly. > > ---------------------------------------------------------------------- > ---------------------------- > rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake > runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ > m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import_version -- > import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS > include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/src/m3makefile > 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > ---------------------------------------------------------------------- > ---------------------------- > > Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's > ftp site into > /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my > library > locations and -gstabs to m3-link. I did a cvs update for the whole > cm3 head, > then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - > build and cm3 -ship. > > -- > ------------------------------------------------------------- > 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 Thu Aug 16 18:47:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:47:36 -0400 Subject: [M3devel] Windows In-Reply-To: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> References: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> Message-ID: I should have realized of course that there is a very simple fix for compilation on the NT386 target using the native m3back backend! Simply make LONGINT=Int32. Jay, I have just checked in this very simple fix to Target.m3 which should permit you to bootstrap a new cm3 and compile the current CVS head. On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > With the current native Windows backend (m3back) blindly assuming > (without even checking!) that all integer operations are 32-bit, I > wonder if anyone out there has the expertise, time, or inclination > to smarten it up to handle both 32-bit and 64-bit ops. It should > not be *too* hard, but I don't have the time for it now, though I > would be happy to answer any questions that arise. Unfortunately, > this reveals that Windows support is withering on the vine, in > spite of Jay's excellent recent work. As of now, this means that > Windows can only build CVS sources with the tag > devel_LONGINT_start. Bridging the gap will require smartening up > m3back or using the gcc-based backend. > From hosking at cs.purdue.edu Thu Aug 16 19:13:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:13:06 -0400 Subject: [M3devel] AMD64 Message-ID: I seem to recall that someone had been working on a Linux AMD64 target. I'd like to get that working and would be interested in any progress that's been made in that direction. From stsp at elego.de Thu Aug 16 19:25:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:25:15 +0200 Subject: [M3devel] AMD64 In-Reply-To: References: Message-ID: <20070816172515.GC15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:18:13 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:18:13 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816171813.GB15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:46:55 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:46:55 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816174655.GD15579@jack.stsp.lan> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. I'd favour listing libiconv as an explicit dependency of cm3. I've looked into this, and --disable-nls is not sufficient to remove gcc's dependency on libiconv. It unconditionally depends on libiconv if it can find the library on the system, regardless of flags passed to the configure script. I've tried hacking iconv detection out of the build system. There's a diff below against cm3-5.4 that removes cm3cg's dependency on libiconv. But it is very ugly. m3gdb also unconditionally depends on libiconv. I have not looked into that. I cannot deinstall libiconv on our Solaris box to prevent configure from picking it up because I don't have root, and I don't really think it's a good idea to begin with because removing the library would probably break a lot of dependencies. Alex, could you provide more details on what gcc backend you are using? Does the ezm3 equivalent of the cm3cg executable depend on libiconv? % ldd /usr/local/cm3/bin/cm3cg libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 With the patch below I get: % ldd /usr/stsp/cm3/bin/cm3cg libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 Index: src/m3makefile =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 m3makefile --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 @@ -126,7 +126,8 @@ if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." + & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", Index: gcc/gcc/Makefile.in =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 @@ -471,8 +471,8 @@ LIBINTL_DEP = @LIBINTL_DEP@ # Character encoding conversion library. -LIBICONV = @LIBICONV@ -LIBICONV_DEP = @LIBICONV_DEP@ +#LIBICONV = @LIBICONV@ +#LIBICONV_DEP = @LIBICONV_DEP@ # The GC method to be used on this system. GGC=@GGC at .o @@ -718,7 +718,7 @@ BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a # Dependencies on the intl and portability libraries. -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) # Likewise, for use in the tools that must run on this machine # even if we are cross-building GCC. @@ -726,7 +726,7 @@ # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:49:56 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:49:56 +0200 Subject: [M3devel] AMD64 In-Reply-To: <20070816172515.GC15579@jack.stsp.lan> References: <20070816172515.GC15579@jack.stsp.lan> Message-ID: <20070816174956.GE15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 07:25:15PM +0200, Stefan Sperling wrote: > <<< No Message Collected >>> > --oTHb8nViIGeoXxdp-- Sorry, local sendmail screw up. Manually messing with the mail queue is not a good idea :-/ Here is the message again: On Thu, Aug 16, 2007 at 01:13:06PM -0400, Tony Hosking wrote: > I seem to recall that someone had been working on a Linux AMD64 target. > I'd like to get that working and would be interested in any progress that's > been made in that direction. That was me. It was more than 2 years ago. The problem back then was that the gcc backend kept segfaulting while trying to bootstrap a native cm3 for amd64. The front end is pretty much done iirc. We anticipated an update of the backend to see if that would fix things. Since you've done the update long ago at this stage, I guess it's worth trying to merge the diff into the current tree, minus the now obsolete system call wrappers in the diff. Maybe things just work. The diff is here: http://www.stsp.name/cm3/cm3-linux-amd64-2005-04-18.patch -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 19:53:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:53:42 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816174655.GD15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> Message-ID: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> I just built cm3cg on SPARC: hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 hosking at arthur ~-> No libiconv... The bootstrap compiler (cm3) and backend (cm3cg) are available at ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and cm3cg.gz. These are both built from the CVS head and contain LONGINT support. On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >> Is it possible to configure it with --disable-nls? That's what we >> tend >> to do for our GCC builds as well. I just looked at the EZM3 >> install we >> have and it doesn't seem like it requires libiconv. > > I'd favour listing libiconv as an explicit dependency of cm3. > > I've looked into this, and --disable-nls is not sufficient to remove > gcc's dependency on libiconv. It unconditionally depends on libiconv > if it can find the library on the system, regardless of flags passed > to the configure script. > > I've tried hacking iconv detection out of the build system. > There's a diff below against cm3-5.4 that removes cm3cg's > dependency on libiconv. But it is very ugly. > > m3gdb also unconditionally depends on libiconv. > I have not looked into that. > > I cannot deinstall libiconv on our Solaris box to prevent configure > from picking it up because I don't have root, and I don't really think > it's a good idea to begin with because removing the library would > probably break a lot of dependencies. > > Alex, could you provide more details on what gcc backend you are > using? > Does the ezm3 equivalent of the cm3cg executable depend on libiconv? > > > % ldd /usr/local/cm3/bin/cm3cg > libiconv.so.2 => /usr/local/lib/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > With the patch below I get: > > % ldd /usr/stsp/cm3/bin/cm3cg > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > > Index: src/m3makefile > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v > retrieving revision 1.16.2.1 > diff -u -r1.16.2.1 m3makefile > --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 > +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 > @@ -126,7 +126,8 @@ > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & > "configure", > + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." > + & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > Index: gcc/gcc/Makefile.in > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v > retrieving revision 1.6 > diff -u -r1.6 Makefile.in > --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 > +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 > @@ -471,8 +471,8 @@ > LIBINTL_DEP = @LIBINTL_DEP@ > > # Character encoding conversion library. > -LIBICONV = @LIBICONV@ > -LIBICONV_DEP = @LIBICONV_DEP@ > +#LIBICONV = @LIBICONV@ > +#LIBICONV_DEP = @LIBICONV_DEP@ > > # The GC method to be used on this system. > GGC=@GGC at .o > @@ -718,7 +718,7 @@ > BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a > > # Dependencies on the intl and portability libraries. > -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) > +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) > > # Likewise, for use in the tools that must run on this machine > # even if we are cross-building GCC. > @@ -726,7 +726,7 @@ > > # How to link with both our special library facilities > # and the system's installed libraries. > -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) > +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) > > # Any system libraries needed just for GNAT. > SYSLIBS = @GNAT_LIBEXC@ > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From hosking at cs.purdue.edu Thu Aug 16 19:54:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:54:55 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: PS Here is how I configured building in m3cc/SOLgnu: ../gcc/configure --enable-languages=m3cg --disable-nls On Aug 16, 2007, at 1:53 PM, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... > > The bootstrap compiler (cm3) and backend (cm3cg) are available at > ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and > cm3cg.gz. These are both built from the CVS head and contain > LONGINT support. > > > On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > >> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >>> Is it possible to configure it with --disable-nls? That's what we >>> tend >>> to do for our GCC builds as well. I just looked at the EZM3 >>> install we >>> have and it doesn't seem like it requires libiconv. >> >> I'd favour listing libiconv as an explicit dependency of cm3. >> >> I've looked into this, and --disable-nls is not sufficient to remove >> gcc's dependency on libiconv. It unconditionally depends on libiconv >> if it can find the library on the system, regardless of flags passed >> to the configure script. >> >> I've tried hacking iconv detection out of the build system. >> There's a diff below against cm3-5.4 that removes cm3cg's >> dependency on libiconv. But it is very ugly. >> >> m3gdb also unconditionally depends on libiconv. >> I have not looked into that. >> >> I cannot deinstall libiconv on our Solaris box to prevent configure >> from picking it up because I don't have root, and I don't really >> think >> it's a good idea to begin with because removing the library would >> probably break a lot of dependencies. >> >> Alex, could you provide more details on what gcc backend you are >> using? >> Does the ezm3 equivalent of the cm3cg executable depend on libiconv? >> >> >> % ldd /usr/local/cm3/bin/cm3cg >> libiconv.so.2 => /usr/local/lib/libiconv.so.2 >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> With the patch below I get: >> >> % ldd /usr/stsp/cm3/bin/cm3cg >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> >> Index: src/m3makefile >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v >> retrieving revision 1.16.2.1 >> diff -u -r1.16.2.1 m3makefile >> --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 >> +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 >> @@ -126,7 +126,8 @@ >> if stale(donep, donep) >> if equal (M3CC_HOST, M3CC_TARGET) >> if equal (M3CC_TARGET, "SOLgnu") >> - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & >> "configure", >> + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." >> + & SL & "gcc" & SL & "configure", >> M3CC_CONFIG, >> "--srcdir=.." & SL & "gcc", >> "--enable-languages=m3cg", >> Index: gcc/gcc/Makefile.in >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v >> retrieving revision 1.6 >> diff -u -r1.6 Makefile.in >> --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 >> +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 >> @@ -471,8 +471,8 @@ >> LIBINTL_DEP = @LIBINTL_DEP@ >> >> # Character encoding conversion library. >> -LIBICONV = @LIBICONV@ >> -LIBICONV_DEP = @LIBICONV_DEP@ >> +#LIBICONV = @LIBICONV@ >> +#LIBICONV_DEP = @LIBICONV_DEP@ >> >> # The GC method to be used on this system. >> GGC=@GGC at .o >> @@ -718,7 +718,7 @@ >> BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a >> >> # Dependencies on the intl and portability libraries. >> -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) >> +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) >> >> # Likewise, for use in the tools that must run on this machine >> # even if we are cross-building GCC. >> @@ -726,7 +726,7 @@ >> >> # How to link with both our special library facilities >> # and the system's installed libraries. >> -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) >> +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) >> >> # Any system libraries needed just for GNAT. >> SYSLIBS = @GNAT_LIBEXC@ >> >> -- >> Stefan Sperling Software Developer >> elego Software Solutions GmbH HRB 77719 >> Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 >> 13355 Berlin Fax: +49 30 23 45 86 95 >> http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > From stsp at elego.de Thu Aug 16 19:59:30 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:59:30 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816175930.GG15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... Is that because you don't have libiconv installed on your system? -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:10:04 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 20:10:04 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816181004.GH15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:54:55PM -0400, Tony Hosking wrote: > PS Here is how I configured building in m3cc/SOLgnu: > > ../gcc/configure --enable-languages=m3cg --disable-nls --disable-nls makes no difference at all with respect to libiconv. See my previous mail. All --disable-nls does is remove a dependency on libintl. This is not a Solaris-only problem. We can either: 1) Build cm3 releases on boxes that haven't got libiconv installed. 2) Declare libiconv an official dependency of cm3. 3) Hack the dependency on libiconv out of the build systems of cm3cg and m3gdb, and possibly others. 1) is a pain for people making releases. 2) is easy for developers, and nothing changes for users because we've always implicitly depended on libiconv without noticing. I've posted a crude patch that does 3) for cm3cg, but not for m3gdb. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 20:28:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 14:28:56 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816175930.GG15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <20070816175930.GG15579@jack.stsp.lan> Message-ID: On Aug 16, 2007, at 1:59 PM, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: >> I just built cm3cg on SPARC: >> >> hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg >> libc.so.1 => /usr/lib/libc.so.1 >> libdl.so.1 => /usr/lib/libdl.so.1 >> /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 >> hosking at arthur ~-> >> >> No libiconv... > > Is that because you don't have libiconv installed on your system? Hmm. The version of gcc I built cm3cg with was bootstrapped from a configuration: ../gcc/configure --prefix=/p/sss/gcc-4.1 --enable-languages=c On inspection, it appears that there is no libiconv installed in /p/ sss/gcc-4.1/lib. hosking at arthur ~-> ls -l /p/sss/gcc-4.1/lib total 2280 drwxr-sr-x 3 hosking sssadmin 4096 Aug 16 12:48 gcc/ lrwxrwxrwx 1 hosking sssadmin 13 Aug 16 12:49 libgcc_s.so -> libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 234060 Aug 16 12:49 libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 816456 Aug 16 12:49 libiberty.a -rw-r--r-- 1 hosking sssadmin 47164 Aug 16 12:49 libssp.a -rwxr-xr-x 1 hosking sssadmin 732 Aug 16 12:49 libssp.la* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so -> libssp.so.0.0.0* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so.0 -> libssp.so.0.0.0* -rwxr-xr-x 1 hosking sssadmin 29060 Aug 16 12:49 libssp.so.0.0.0* -rw-r--r-- 1 hosking sssadmin 2200 Aug 16 12:49 libssp_nonshared.a -rwxr-xr-x 1 hosking sssadmin 714 Aug 16 12:49 libssp_nonshared.la* drwxr-sr-x 2 hosking sssadmin 4096 Aug 16 12:49 sparcv9/ hosking at arthur ~-> > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From rodney.bates at wichita.edu Thu Aug 16 22:49:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 15:49:08 -0500 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Message-ID: <46C4B844.3080901@wichita.edu> No, I hadn't, but it didn't help. Note it is in m3core that the .M3EXPORTS is not found, while I was trying to compile in m3middle. In any case, it should be normal to do a compile in a directory that has a partially populated LINUXLIBC6 (or whatever), expecting the compiler to figure out what to do. I tried departing from the listed order and building/shipping m3core and libm3, before m3middle, and that got the bootstrap going. These did not have a LINUXLIBC6 directory, I suppose because of the realclean. Tony Hosking wrote: > Did you "rm -rf LINUXLIBC6" before "cm3 -build"? > > On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > >> What does the following failure mean? I run into it regularly. >> >> ---------------------------------------------------------------------- >> ---------------------------- >> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ >> m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >> >> --procedure-- -line- -file--- >> import_version -- >> import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS >> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/src/m3makefile >> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/LINUXLIBC6/m3make.args >> >> Fatal Error: package build failed >> >> ---------------------------------------------------------------------- >> ---------------------------- >> >> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp >> site into >> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library >> locations and -gstabs to m3-link. I did a cvs update for the whole >> cm3 head, >> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - build >> and cm3 -ship. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 16 23:19:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 16:19:08 -0500 Subject: [M3devel] A strange link time warning using cm3 Message-ID: <46C4BF4C.9070706@wichita.edu> When linking a program of my own, using cm3 from the cvs head, I get this warning: ----------------------------------------------------------------------------------------------------- -> linking LdlBatch /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In function `TrestleOS__UserName': /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ----------------------------------------------------------------------------------------------------- And a few more just like it. This doesn't make any sense to me. If a "statically linked application" is what it says it is, why would it require at runtime, any shared library at all, let alone a specific version? -- ------------------------------------------------------------- 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 Thu Aug 16 23:26:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 17:26:47 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4B844.3080901@wichita.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> <46C4B844.3080901@wichita.edu> Message-ID: Sounds like you are getting overrides or something. Certainly is strange behavior, which I don't see. On Aug 16, 2007, at 4:49 PM, Rodney M. Bates wrote: > No, I hadn't, but it didn't help. Note it is in m3core that the > .M3EXPORTS is not found, while I was trying to compile in m3middle. > > In any case, it should be normal to do a compile in a directory > that has a partially populated LINUXLIBC6 (or whatever), expecting > the compiler to figure out what to do. > > I tried departing from the listed order and building/shipping > m3core and libm3, before m3middle, and that got the bootstrap > going. These did not have a LINUXLIBC6 directory, I suppose > because of the realclean. > > Tony Hosking wrote: >> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? >> On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: >>> What does the following failure mean? I run into it regularly. >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >>> --- building in LINUXLIBC6 --- >>> >>> ignoring ../src/m3overrides >>> >>> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >>> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/ >>> cm3/ m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >>> >>> --procedure-- -line- -file--- >>> import_version -- >>> import 4 /usr/local/cm3/pkg/libm3/ >>> LINUXLIBC6/.M3EXPORTS >>> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/src/m3makefile >>> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/LINUXLIBC6/m3make.args >>> >>> Fatal Error: package build failed >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> >>> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's >>> ftp site into >>> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my >>> library >>> locations and -gstabs to m3-link. I did a cvs update for the >>> whole cm3 head, >>> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - >>> build and cm3 -ship. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From roland.illig at gmx.de Fri Aug 17 00:26:48 2007 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 17 Aug 2007 00:26:48 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <46C4CF28.8090001@gmx.de> Rodney M. Bates wrote: > This doesn't make any sense to me. If a "statically linked > application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? The user, group, host, whatever databases uses a plug-in mechanism on Linux (something called nsswitch or similar). The plug-ins can be an SQL database, LDAP, PAM, traditional password files and so on. Since the exact set of plug-ins is not known at compile-time, shared libraries must be used in this case. Roland From wagner at elegosoft.com Fri Aug 17 09:54:42 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 09:54:42 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 23:19, Rodney M. Bates wrote: > When linking a program of my own, using cm3 from the cvs head, I get this > warning: > ----------------------------------------------------------------------------------------------------- > -> linking LdlBatch > /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In > function > `TrestleOS__UserName': > /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: > warning: Using 'getpwuid' in > statically linked applications requires at runtime the shared libraries from > the glibc version used > for linking > ----------------------------------------------------------------------------------------------------- > > And a few more just like it. This doesn't make any sense to me. If a > "statically > linked application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? As Roland Illig already pointed out, modern operating systems don't really support traditional static linking if you are using certain functionality (which accidentally is needed by almost all programs ;-). Nonetheless the warnings you get point to a problem with the CM3 setup: those libraries that need to be plugged-in by the OS must not be linked statically. In cm3.cfg the set up system libraries should be separated into those that need dynamic linking and others. All system libraries that need dynamic linking should be linked this way, regardless of the cm3 arguments. This way `statically linked' refers only to the CM3 libraries and not to the -- always available -- operating system libraries, and can still be a help for delivering independent programs written in M3. Stefan, I thought we had resolved this issue at least for Linux and Solaris setups with the last release. Did we miss something? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Aug 17 14:19:02 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 17 Aug 2007 14:19:02 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> Message-ID: <20070817121902.GB10092@jack.stsp.lan> On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: > Stefan, I thought we had resolved this issue at least for Linux and > Solaris setups with the last release. Did we miss something? We link system libraries dynamically on these platforms. It could be that Rodney's own program does not link libraries dynamically, so he gets the warning. This is the diff that introduced dynamic linking on Linux. Note that we explicitly enable dynamic linking on a per-library basis... maybe we should enforce dynamic linking in general? Index: LINUXLIBC6 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cm3/src/config/LINUXLIBC6,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- LINUXLIBC6 6 Aug 2006 12:46:03 -0000 1.7 +++ LINUXLIBC6 1 Sep 2006 13:42:23 -0000 1.8 @@ -98,14 +98,14 @@ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], -% "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms - "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], - "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], - "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], - "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], - "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", +% "LEX-YACC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-ll" ], %-- not on most Linux platforms + "FLEX-BISON" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lfl" ], + "POSTGRES95" : [ "-Xlinker", "-Bdynamic", "-L/usr/local/postgres95/lib", "-lpq" ], + "OPENGL" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], + "MOTIF" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXm" ], + "X11" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], - "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], + "PTHREAD" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Aug 17 14:54:04 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 14:54:04 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <20070817121902.GB10092@jack.stsp.lan> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> Message-ID: <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> Stefan, I thought we had resolved this issue at least for Linux and >> Solaris setups with the last release. Did we miss something? > > We link system libraries dynamically on these platforms. > > It could be that Rodney's own program does not link > libraries dynamically, so he gets the warning. > > This is the diff that introduced dynamic linking on Linux. > Note that we explicitly enable dynamic linking on a per-library > basis... maybe we should enforce dynamic linking in general? [diff removed] No, I only want to find out why Rodney gets those warnings. Either he hasn't the cm3.cfg changes from the last release, or some other packages (Trestle?) import more libraries which cause the problem. Rodney, could you please check that? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Aug 17 22:26:02 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 17 Aug 2007 15:26:02 -0500 Subject: [M3devel] A strange link time warning using cm3] Message-ID: <46C6045A.6050402@wichita.edu> I usually just manually edit my old cm3.cfg files, because I usually have to merge my local library locations, etc. And I haven't done a cminstall in a while. So I don't have the official version. Right now, I have none of the libraries dynamically linked. I just didn't realize there were some of them that would not work on. From my cm3.cfg on the machine where I got the quoted message (running Linux Mandrake 10.2): ------------------------------------------------------------------------ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } ------------------------------------------------------------------------ Even so, the warning only happens when I compile a program with build_standalone ( ) in the m3makefile. I guess I'll put back the -Xlinker -Bdynamic in the libraries that Stefan's diff shows. Will this change anything other than getting rid of the warning message? After I read about dynamic linking in the 60's on the Multics system, I always thought it was a great idea. After decades of waiting, I gave up ever seeing it in anything but a research OS. Now that it has become universal, I have often wondered if we would be better to put that genie back in the bottle. Library version skew, when moving from machine to machine can be a nightmare, even when your OS does allow multiple versions to be installed simultaneously. But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. Olaf Wagner wrote: > On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > >>On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> >>>Stefan, I thought we had resolved this issue at least for Linux and >>>Solaris setups with the last release. Did we miss something? >> >>We link system libraries dynamically on these platforms. >> >>It could be that Rodney's own program does not link >>libraries dynamically, so he gets the warning. >> >>This is the diff that introduced dynamic linking on Linux. >>Note that we explicitly enable dynamic linking on a per-library >>basis... maybe we should enforce dynamic linking in general? > > [diff removed] > > No, I only want to find out why Rodney gets those warnings. > Either he hasn't the cm3.cfg changes from the last release, or > some other packages (Trestle?) import more libraries which cause > the problem. Rodney, could you please check that? > > Olaf -- ------------------------------------------------------------- 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 rcoleburn at scires.com Fri Aug 17 23:26:20 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Aug 2007 17:26:20 -0400 Subject: [M3devel] A strange link time warning using cm3] In-Reply-To: <46C6045A.6050402@wichita.edu> References: <46C6045A.6050402@wichita.edu> Message-ID: <46C5DA31.1E75.00D7.1@scires.com> >>> "Rodney M. Bates" rodney.bates at wichita.edu> 8/17/2007 4:26 PM >> ( mailto:rodney.bates at wichita.edu> ) .... But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. .... I thought that the buildstandalone() directive in the m3makefile is supposed to cause linking with static libraries. At least that is what happens in cm3 v4.1. Regards, Randy Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Aug 18 02:47:36 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 02:47:36 +0200 Subject: [M3devel] strange... Message-ID: <1187398056.31487.17.camel@faramir.m3w.org> I am getting this... No idea where it gosts imported, and being so late here... Maybe I can find answer when I woke :). TIA. As far as I know, this is full boostrap by latest instructions from cvshead over earlier revision. ... -> linking hcca /usr/bin/ld: cannot find -lm3gcdefs collect2: ld returned 1 exit status Fatal Error: package build failed -- Dragi?a Duri? From jayk123 at hotmail.com Sat Aug 18 04:37:22 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 18 Aug 2007 02:37:22 +0000 Subject: [M3devel] Windows Message-ID: I have the inclination, still working on time and expertise. :) Summarize the layering for me? Which module calls which?Your mention below of the assumption of 32 bit ops at least confirms what I thought I vaguely understood reading through the source. It's just a bunch of pretty dense code without documentation, the sort I write myself when I have the whole program in my head and just need to type it all in as quickly as possible. Would the idea be to use a tagged union for this stack, or to split 64 bits ops into pairs of 32 bit ops? You know, like, does this stack translate "closely" to the generated code, or not? If it does, pairs, if it does not, tagged union. Probably. Similarly, like, all the register dealings need some notion of pairs..? Maybe I should look at the other backend to understand better, if there is an analogous bunch of code. Anyway, I'll try at least this weekend to verify that it's buildable asis, i know that's just a teeny tiny baby step, just push the button to build, a monkey could do it... my expertise is beyond that, but... I suspect tagged union is it, and have to churn a bunch of code to check the type. ugh. lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 bit type). ?? Thanks, - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: Windows> Date: Thu, 16 Aug 2007 12:47:36 -0400> To: jay.krell at cornell.edu; jayk123 at hotmail.com> > I should have realized of course that there is a very simple fix for > compilation on the NT386 target using the native m3back backend! > Simply make LONGINT=Int32. Jay, I have just checked in this very > simple fix to Target.m3 which should permit you to bootstrap a new > cm3 and compile the current CVS head.> > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote:> > > With the current native Windows backend (m3back) blindly assuming > > (without even checking!) that all integer operations are 32-bit, I > > wonder if anyone out there has the expertise, time, or inclination > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > not be *too* hard, but I don't have the time for it now, though I > > would be happy to answer any questions that arise. Unfortunately, > > this reveals that Windows support is withering on the vine, in > > spite of Jay's excellent recent work. As of now, this means that > > Windows can only build CVS sources with the tag > > devel_LONGINT_start. Bridging the gap will require smartening up > > m3back or using the gcc-based backend.> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 18 11:52:52 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Aug 2007 11:52:52 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C5C599.9010306@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> <46C5C599.9010306@wichita.edu> Message-ID: <20070818095252.GA10785@elegosoft.com> On Fri, Aug 17, 2007 at 10:58:17AM -0500, Rodney M. Bates wrote: > I usually just manually edit my old cm3.cfg files, because I usually > have to merge my local library locations, etc. And I haven't done a > cminstall in a while. So I don't have the official version. > > Right now, I have none of the libraries dynamically linked. I just > didn't realize there were some of them that would not work on. > > From my cm3.cfg on the machine where I got the quoted message > (running Linux Mandrake 10.2): > > ------------------------------------------------------------------------ > SYSTEM_LIBS = { > "LIBC" : [ "-lm" ], > % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms > "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], > "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], > "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], > "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], > "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", > "-lXt", "-lSM", "-lICE", "-lX11" ], > "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], > "TCP" : [ ] > } > ------------------------------------------------------------------------ OK, so you're just missing the dynamic hints in the linker setup. Could you please verify that that's all and we've found everything that needs to be linker dynamically unconditionally? > Even so, the warning only happens when I compile a program with > build_standalone ( ) in the m3makefile. The default has long been to link dynamically; build_standalone should switch to static linking wherever possible. > I guess I'll put back the -Xlinker -Bdynamic in the libraries that > Stefan's diff shows. Will this change anything other than getting > rid of the warning message? I hope not. > > After I read about dynamic linking in the 60's on the Multics system, > I always thought it was a great idea. After decades of waiting, I gave > up ever seeing it in anything but a research OS. Now that it has become > universal, I have often wondered if we would be better to put that genie > back in the bottle. Library version skew, when moving from machine to > machine can be a nightmare, even when your OS does allow multiple versions > to be installed simultaneously. But at least, I thought, the option to do > full static linking was still there, for those who chose it. So it is a > bit of a shock to learn that that option is now gone. > I'm with you there; I experienced the same feeling some years ago :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sat Aug 18 19:35:17 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 19:35:17 +0200 Subject: [M3devel] strange... And also some CM3isms In-Reply-To: <1187398056.31487.17.camel@faramir.m3w.org> References: <1187398056.31487.17.camel@faramir.m3w.org> Message-ID: <1187458517.31487.21.camel@faramir.m3w.org> One of packages was left behind while rebuilding... Of course there is no m3gcdefs in cm4 cvshead... Long ago I remember reading about runtime errors being exceptions (in CM3) and also RETURN and EXIT.... Is there some example code on how to use this? On Sat, 2007-08-18 at 02:47 +0200, Dragi?a Duri? wrote: > I am getting this... No idea where it gosts imported, and being so late > here... Maybe I can find answer when I woke :). TIA. > > As far as I know, this is full boostrap by latest instructions from > cvshead over earlier revision. > > ... > -> linking hcca > /usr/bin/ld: cannot find -lm3gcdefs > collect2: ld returned 1 exit status > Fatal Error: package build failed > -- Dragi?a Duri? From hosking at cs.purdue.edu Sat Aug 18 22:18:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Aug 2007 16:18:09 -0400 Subject: [M3devel] Windows In-Reply-To: References: Message-ID: <835F3374-48D2-4785-A82B-87792B1A483C@cs.purdue.edu> On Aug 17, 2007, at 10:37 PM, j k wrote: > I have the inclination, still working on time and expertise. :) > Summarize the layering for me? Which module calls which? > Your mention below of the assumption of 32 bit ops at least > confirms what I thought I vaguely understood reading through the > source. It's just a bunch of pretty dense code without > documentation, the sort I write myself when I have the whole > program in my head and just need to type it all in as quickly as > possible. Would the idea be to use a tagged union for this stack, > or to split 64 bits ops into pairs of 32 bit ops? > You know, like, does this stack translate "closely" to the > generated code, or not? If it does, pairs, if it does not, tagged > union. Probably. Similarly, like, all the register dealings need > some notion of pairs..? Maybe I should look at the other backend to > understand better, if there is an analogous bunch of code. You'll notice that the M3CG interface has many ops that take ZType= [Int32, Word32, Int64, Word64]. Unfortunatly M3x86.m3 and Stackx86.m3 simply drop those types on the floor (or simply distinguishes Word32 from Int32). I don't know the m3back code well at all, so I have no idea how tough it might be to smarten it up for Int64/Word64. > Anyway, I'll try at least this weekend to verify that it's > buildable asis, i know that's just a teeny tiny baby step, just > push the button to build, a monkey could do it... my expertise is > beyond that, but... Should be fine now, though INTEGER and LONGINT are both 32-bits for NT386 target. > > I suspect tagged union is it, and have to churn a bunch of code to > check the type. ugh. > lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 > bit type). Not sure... > > ?? > > Thanks, > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: Windows > > Date: Thu, 16 Aug 2007 12:47:36 -0400 > > To: jay.krell at cornell.edu; jayk123 at hotmail.com > > > > I should have realized of course that there is a very simple fix for > > compilation on the NT386 target using the native m3back backend! > > Simply make LONGINT=Int32. Jay, I have just checked in this very > > simple fix to Target.m3 which should permit you to bootstrap a new > > cm3 and compile the current CVS head. > > > > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > > > > > With the current native Windows backend (m3back) blindly assuming > > > (without even checking!) that all integer operations are 32-bit, I > > > wonder if anyone out there has the expertise, time, or inclination > > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > > not be *too* hard, but I don't have the time for it now, though I > > > would be happy to answer any questions that arise. Unfortunately, > > > this reveals that Windows support is withering on the vine, in > > > spite of Jay's excellent recent work. As of now, this means that > > > Windows can only build CVS sources with the tag > > > devel_LONGINT_start. Bridging the gap will require smartening up > > > m3back or using the gcc-based backend. > > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Mon Aug 20 14:01:23 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 20 Aug 2007 14:01:23 +0200 Subject: [M3devel] subrange or enum, with cvshead Message-ID: <1187611284.31487.42.camel@faramir.m3w.org> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 (skipping m3gdb, which I've reported earlier would not compile for me) I am getting this error when I try to rn one of programs that worked flawlessy few checkouts ago. *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** This is corresponding code: now := Time.Now() - epoch; >>> time := TRUNC(now); fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, LONGREAL), 8)); I've identified few other problems, but I suppose ther are all variations... -- Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:46:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:46:24 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: Hmmm. Are you using the most recent cm3cg, and a compiler bootstrapped with it? Also, I have not tested the LONGINT stuff extensively on AMD64 yet. Any chance you can diagnose the problem? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:59:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:59:19 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: I think I've tracked this down to Time.Now returning 0. Hmmm. How could this be? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:04:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:04:49 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187635746.31487.50.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> Message-ID: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> I've figured out the cure, but don't know why the problem exists. It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE constants when built on AMD64, unless it is configured as: CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls --enable-targets=x86-linux If you omit CC="gcc -m32" then the problem arises. I have put my AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and do not represent a complete 64-bit port to AMD64. See cm3.cfg, cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6- AMD64. On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > I've bootstrapped it same way as on ix86, first m3cc...cm3, then > setting > CM3 env var, then std build... > > When I just rsynced my INSTALL_ROOT and built binaries... it works, of > course. > > As for Time.Now()... I have few other problems happening... Do you > have > some kind of test code for LONGINT I can run on this AMD64 box? > > dd > > On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >> Hmmm. Are you using the most recent cm3cg, and a compiler >> bootstrapped with it? >> >> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >> Any chance you can diagnose the problem? >> >> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >> >>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>> (skipping >>> m3gdb, which I've reported earlier would not compile for me) I am >>> getting this error when I try to rn one of programs that worked >>> flawlessy few checkouts ago. >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>> *** >>> >>> This is corresponding code: >>> >>> now := Time.Now() - epoch; >>>>>> time := TRUNC(now); >>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>> LONGREAL), 8)); >>> >>> I've identified few other problems, but I suppose ther are all >>> variations... >>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:30:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:30:43 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> Message-ID: <27A835EB-4FA5-49B6-A30B-900361904CEF@cs.purdue.edu> PS I've successfully bootstrapped 32-bit LINUXLIBC6 on AMD64 and run mentor Bresenham using the bottstrap binaries from my ftp site. On Aug 20, 2007, at 7:04 PM, Tony Hosking wrote: > I've figured out the cure, but don't know why the problem exists. > It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE > constants when built on AMD64, unless it is configured as: > > CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable- > nls --enable-targets=x86-linux > > If you omit CC="gcc -m32" then the problem arises. I have put my > AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the > directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, > and do not represent a complete 64-bit port to AMD64. See cm3.cfg, > cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ > LINUXLIBC6-AMD64. > > On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > >> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >> setting >> CM3 env var, then std build... >> >> When I just rsynced my INSTALL_ROOT and built binaries... it >> works, of >> course. >> >> As for Time.Now()... I have few other problems happening... Do you >> have >> some kind of test code for LONGINT I can run on this AMD64 box? >> >> dd >> >> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>> Hmmm. Are you using the most recent cm3cg, and a compiler >>> bootstrapped with it? >>> >>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>> Any chance you can diagnose the problem? >>> >>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>> >>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>> (skipping >>>> m3gdb, which I've reported earlier would not compile for me) I am >>>> getting this error when I try to rn one of programs that worked >>>> flawlessy few checkouts ago. >>>> >>>> *** >>>> *** runtime error: >>>> *** An enumeration or subrange value was out of range. >>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>> *** >>>> >>>> This is corresponding code: >>>> >>>> now := Time.Now() - epoch; >>>>>>> time := TRUNC(now); >>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>> LONGREAL), 8)); >>>> >>>> I've identified few other problems, but I suppose ther are all >>>> variations... >>>> >>>> -- >>>> Dragi?a Duri? >>> >> -- >> Dragi?a Duri? > From wagner at elegosoft.com Tue Aug 21 08:57:47 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Aug 2007 08:57:47 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> On Tue, August 21, 2007 05:07, Alex Bochannek wrote: > I finally got around to completing a successful buildship on Solaris 10 > on SPARC. Here are the steps I did. > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) Without haveing investigated any of the issues above -- all this sounds to me like you are using a quite old Solaris system. I'd like to see the exact versions you and Tony use to build the software (uname -a). At least it might be a different worth to docuement. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Aug 21 15:54:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:54:09 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187674684.31487.54.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> <1187674684.31487.54.camel@faramir.m3w.org> Message-ID: <0558ABE2-AEB9-42F0-8E62-A5B0A3E74BE7@cs.purdue.edu> I generally skip m3gdb. I haven't tried it on AMD64. On Aug 21, 2007, at 1:38 AM, Dragi?a Duri? wrote: > Can this be a problem with m3gdb not building, LINUXLIBC6 target on > AMD64? Is it built on your machine? > > dd > > On Mon, 2007-08-20 at 19:04 -0400, Tony Hosking wrote: >> I've figured out the cure, but don't know why the problem exists. It >> seems that the gcc-based backend builds incorrect FLOAT/DOUBLE >> constants when built on AMD64, unless it is configured as: >> >> CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls >> --enable-targets=x86-linux >> >> If you omit CC="gcc -m32" then the problem arises. I have put my >> AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the >> directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and >> do not represent a complete 64-bit port to AMD64. See cm3.cfg, >> cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ >> LINUXLIBC6- >> AMD64. >> >> On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: >> >>> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >>> setting >>> CM3 env var, then std build... >>> >>> When I just rsynced my INSTALL_ROOT and built binaries... it >>> works, of >>> course. >>> >>> As for Time.Now()... I have few other problems happening... Do you >>> have >>> some kind of test code for LONGINT I can run on this AMD64 box? >>> >>> dd >>> >>> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>>> Hmmm. Are you using the most recent cm3cg, and a compiler >>>> bootstrapped with it? >>>> >>>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>>> Any chance you can diagnose the problem? >>>> >>>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>>> >>>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>>> (skipping >>>>> m3gdb, which I've reported earlier would not compile for me) I am >>>>> getting this error when I try to rn one of programs that worked >>>>> flawlessy few checkouts ago. >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>>> *** >>>>> >>>>> This is corresponding code: >>>>> >>>>> now := Time.Now() - epoch; >>>>>>>> time := TRUNC(now); >>>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>>> LONGREAL), 8)); >>>>> >>>>> I've identified few other problems, but I suppose ther are all >>>>> variations... >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 15:59:01 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:59:01 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> On Aug 20, 2007, at 11:07 PM, Alex Bochannek wrote: > I finally got around to completing a successful buildship on > Solaris 10 > on SPARC. Here are the steps I did. > > o Downloaded cm3-min-POSIX-SOLgnu-5.4.0.tgz and do a cminstall as root > into /usr/local/cm3 > > o In the process, some of the libraries it couldn't find I chose to > ignore (e.g., {PostgreSQL) > > o Downloaded the SOLgnu/cm3.gz and cm3cg.gz from Tony Hosking's site > > o Copied them over the existing ones in /usr/local/cm3 > > o Checked out a top-of-tree CVS version of cm3-src > > o Adjusted Tony's cm3.cfg to my INSTALL_ROOT > > o Did a scripts/do-cm3-core.sh buildship as root > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a > GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and > since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. Which file chokes? Is it because your m3cc is configured to use GNU as? > > o do-cm3-core.sh completed and I did an install-cm3-compiler.sh > upgrade, > again as root since it's writing it into /usr/local/cm3 > > o Finally, did a do-cm3-std.sh buildship, which ran for quite a while. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) > > o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh > buildship again. > > o The compile and install succeeded and I now have a nice new > cm3-d5.5.0. > > o Compiler some stuff in m3-games, just to make sure it really > works and > it looks like I am OK for now. I do see a number of core dumps > though > with some of apps, but I am not going to debug that at this point. What's core dumping? Is this from before my fixes to thread stopping yesterday? > > Thanks for the help and if there is anything I can do to help with > troubleshooting some of the problems on Solaris, I am happy to do so. > > Alex. > > > > Gdb compile error: > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function version.c > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/ > valops.c > In file included from ../../gdb/gdb/m3-lang.h:23, > from ../../gdb/gdb/valops.c:47: > /usr/include/stdbool.h:42:2: #error "Use of is valid > only in a c99 compilation environment." > In file included from ../../gdb/gdb/valops.c:47: > ../../gdb/gdb/m3-lang.h:34: error: syntax error before > "processing_pm3_compilation" > ../../gdb/gdb/m3-lang.h:34: warning: type defaults to `int' in > declaration of `processing_pm3_compilation' > ../../gdb/gdb/m3-lang.h:34: warning: data definition has no type or > storage class > ../../gdb/gdb/m3-lang.h:43: error: syntax error before > "procedures_have_extra_block" > ../../gdb/gdb/m3-lang.h:43: warning: type defaults to `int' in > declaration of `procedures_have_extra_block' > ../../gdb/gdb/m3-lang.h:43: warning: data definition has no type or > storage class > gmake[2]: *** [valops.o] Error 1 > gmake[2]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu/gdb' > gmake[1]: *** [all-gdb] Error 2 > gmake[1]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu' > gmake: *** [all] Error 2 From hosking at cs.purdue.edu Tue Aug 21 16:00:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:00:31 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> Message-ID: <6A045050-347B-4C7D-A185-1E1B240F940F@cs.purdue.edu> I'm the old one: SunOS arthur.cs.purdue.edu 5.8 Generic_117350-47 sun4u sparc SUNW,Sun- Fire-V250 On Aug 21, 2007, at 9:34 AM, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Without haveing investigated any of the issues above -- all this >> sounds to me like you are using a quite old Solaris system. I'd like >> to see the exact versions you and Tony use to build the software >> (uname -a). At least it might be a different worth to docuement. > > Not really. It's a V480 with Solaris 10: > > Kernel version: SunOS 5.10 Generic_118833-17 > > Alex. From hosking at cs.purdue.edu Tue Aug 21 16:52:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:52:18 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> Message-ID: <5F334086-0745-4C8D-9351-48C3B618271A@cs.purdue.edu> Yes, those are because your m3cc backend is configured to us GNU as, so it is just a matter of making sure your cm3.cfg uses the same assembler. In general, these problems are difficult to reconcile. I suspect we want SOLgnu to assume a full GNU toolchain and SOLsun to assume no GNU toolchain, but in many instances systems are configured as some hybrid of the two. For example, my gcc installation on Solaris is configured to use /usr/ccs/bin/as, and I don't have GNU ld installed either -- hence the definitions in my cm3.cfg. On Aug 21, 2007, at 10:21 AM, Alex Bochannek wrote: > Tony Hosking writes: > >>> o Ran into another problem with as and for some reason Tony's >>> cm3.cfg >>> used /usr/ccs/bin/as, which chokes on the GNU as directives. >>> Changed >>> cm3.cfg again. >> >> Which file chokes? Is it because your m3cc is configured to use >> GNU as? > > I get these kinds of errors: > > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: unknown opcode > ".subsection" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: statement syntax > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: unknown opcode > ".previous" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: statement syntax > > for RTHeapMap, RTTipe, RTTypeMap, RTExStack, and Poly when I run > do-cm3-core buildship. > >>> o do-cm3-core.sh completed and I did an install-cm3-compiler.sh >>> upgrade, >>> again as root since it's writing it into /usr/local/cm3 >>> >>> o Finally, did a do-cm3-std.sh buildship, which ran for quite a >>> while. >>> >>> o Ran into compile problems with Gdb (looked like a C99 issue, but I >>> didn't investigate it further. Just ran a cm3 in m3gdb again >>> and the >>> error is below.) >>> >>> o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh >>> buildship again. >>> >>> o The compile and install succeeded and I now have a nice new >>> cm3-d5.5.0. >>> >>> o Compiler some stuff in m3-games, just to make sure it really works >>> and >>> it looks like I am OK for now. I do see a number of core dumps >>> though >>> with some of apps, but I am not going to debug that at this point. >> >> What's core dumping? Is this from before my fixes to thread stopping >> yesterday? > > I just ran into problems with a couple of things out of m3-demo and > m3-games. Don't recall what it was (although Juno won't run right > now), > but I will do a CVS update and build a new system and report back if > something doesn't work. > > Alex. From dragisha at m3w.org Wed Aug 22 11:44:55 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:44:55 +0200 Subject: [M3devel] crashes everywhere Message-ID: <1187775896.31487.97.camel@faramir.m3w.org> *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 2316 *** m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: (m3gdb) bt #0 0x00d54402 in ?? () #1 0x430c7ba0 in raise () from /lib/libc.so.6 #2 0x430c94b1 in abort () from /lib/libc.so.6 #3 0x00eaf2ff in Crash () at RTOS.m3:20 #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 #7 0x00e9f212 in Crash (a= ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion `compiler_kind != ck_pm3' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From dragisha at m3w.org Wed Aug 22 11:58:44 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:58:44 +0200 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <1187776724.31487.103.camel@faramir.m3w.org> Another program, similar code... bt before I do set lang (still no idea why' problem there): #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol table. ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in symbol table. ) at RTCollector.m3:2316 #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol table. ) at Panda.m3:353 Line 353 is: AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); > INC(d.pdf.nextFontNumber); (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); *) AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not declared it "UNTRACED REF", and it is ref to C structure... I see these RTCollector bugs are happening from time to time, so I am posting this because I hope it can help other people identify it before they hit list (as I did:). m3gdb nastyness remains... On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From rodney.bates at wichita.edu Wed Aug 22 16:27:07 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 22 Aug 2007 09:27:07 -0500 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <46CC47BB.1050502@wichita.edu> I was unable to reproduce this m3gdb problem, but I looked at ways this could happen. In your case, m3gdb is getting conflicting information about whether it is debugging a program compiled by pm3 or cm3. As a workaround, since we know (don't we?) that it is actually cm3, and that agrees with what m3gdb thinks at the time of the assertion failure, it is probably safe in this case to ignore the message and proceed. You might even try the bt command again immediately. This error should self-heal at this point. It would be helpful to me if you sent me the output of these commands: objdump -G | grep MM__m3main objdump -G | grep ObjectTypecell Substitute the appropriate paths for your linked executable and wherever it finds libm3core. Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- ------------------------------------------------------------- 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 Wed Aug 22 17:31:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:31:08 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> I can't speak for m3gdb, but something seems seriously wrong with your installation. What program is causing this crash? Please also tell me the version number of ThreadPThread.m3. The most recent version is 1.48 of 2007-08-20. On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:47:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:47:14 -0400 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187776724.31487.103.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <1187776724.31487.103.camel@faramir.m3w.org> Message-ID: On Aug 22, 2007, at 5:58 AM, Dragi?a Duri? wrote: > Another program, similar code... bt before I do set lang (still no > idea > why' problem there): > > #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol > table. > ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in > symbol table. > ) at RTCollector.m3:2316 > #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol > table. > ) at Panda.m3:353 > > Line 353 is: > > AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); > AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); > fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); >> INC(d.pdf.nextFontNumber); > (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); > *) > AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); > > d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not > declared > it "UNTRACED REF", and it is ref to C structure... What is the type of d, d.pdf, and d.pdf.nextFontNumber? Are you saying d.pdf is REF? Yet you are storing an UNTRACED REF in it? The garbage collector will definitely become confused in that situation. Try using gdb instead of m3gdb so I can see the value of the parameter 'ref' passed to CheckStoreTraced from CreateFont. > > I see these RTCollector bugs are happening from time to time, so I am > posting this because I hope it can help other people identify it > before > they hit list (as I did:). > > m3gdb nastyness remains... > > On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 2316 >> *** >> >> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >> >> (m3gdb) bt >> #0 0x00d54402 in ?? () >> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >> #2 0x430c94b1 in abort () from /lib/libc.so.6 >> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >> msgA=16_00ed8ee8, >> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >> #7 0x00e9f212 in Crash (a= >> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >> `compiler_kind != ck_pm3' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> >> I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:51:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:51:28 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187797188.31487.113.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> <1187797188.31487.113.camel@faramir.m3w.org> Message-ID: <86C11DDE-5087-414B-9256-B7727041B020@cs.purdue.edu> On Aug 22, 2007, at 11:39 AM, Dragi?a Duri? wrote: > It is not... It was a bug I've explained in my replly to message you > replied to... Are you saying that fixing the bug made the crash go away? > My code triggers it, but I suppose there is problem with > CheckStoreTraced tracing through REF to C structure... Compiler did > not > complain, ot it did not generate correct info about "untracedness" of > "REF to C structure"... I've fixed my code, but I do not think this > (my > message you replied show it) is correct way for CM3 to react to bug in > code logic. I agree that it would be nice for cm3 to give a warning or error when using REF to C structs, but I need to know how you declared the type to understand what can be checked statically. The alternative is to have CheckStoreTraced complain if it is passed a ref that is not a true heap referent. Can you tell me how you declared things originally? Was it declared that way in UNSAFE code? > dd > > On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: >> I can't speak for m3gdb, but something seems seriously wrong with >> your installation. What program is causing this crash? Please also >> tell me the version number of ThreadPThread.m3. The most recent >> version is 1.48 of 2007-08-20. >> >> On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: >> >>> *** >>> *** runtime error: >>> *** An array subscript was out of range. >>> *** file "../src/runtime/common/RTCollector.m3", line 2316 >>> *** >>> >>> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >>> >>> (m3gdb) bt >>> #0 0x00d54402 in ?? () >>> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >>> #2 0x430c94b1 in abort () from /lib/libc.so.6 >>> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >>> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >>> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >>> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >>> msgA=16_00ed8ee8, >>> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >>> #7 0x00e9f212 in Crash (a= >>> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >>> `compiler_kind != ck_pm3' failed. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> >>> I am using cvshead cm3, as of few days ago. >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 18:01:05 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 12:01:05 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187797188.31487.113.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> <1187797188.31487.113.camel@faramir.m3w.org> Message-ID: On Aug 22, 2007, at 11:39 AM, Dragi?a Duri? wrote: > It is not... It was a bug I've explained in my replly to message you > replied to... > > My code triggers it, but I suppose there is problem with > CheckStoreTraced tracing through REF to C structure... Compiler did > not > complain, ot it did not generate correct info about "untracedness" of > "REF to C structure"... I've fixed my code, but I do not think this > (my > message you replied show it) is correct way for CM3 to react to bug in > code logic. On reflection, it seems that the only way you could create a "REF" to a C structure is in UNSAFE code. In which case, you are the one responsible for the bug, rather than the compiler needing to warn you. Programmers of UNSAFE code need to be very careful when constructing REFs that are not obtained via NEW (I would argue that LOOPHOLE should almost never be used to construct a REF, except when absolutely necessary). Perhaps an appropriate warning would be for such loopholing. Then again programmers of UNSAFE code are assumed to know what they are doing. Of course, in safe code the only way to get a REF is using NEW, so there should be no problems there. > > dd > > On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: >> I can't speak for m3gdb, but something seems seriously wrong with >> your installation. What program is causing this crash? Please also >> tell me the version number of ThreadPThread.m3. The most recent >> version is 1.48 of 2007-08-20. >> >> On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: >> >>> *** >>> *** runtime error: >>> *** An array subscript was out of range. >>> *** file "../src/runtime/common/RTCollector.m3", line 2316 >>> *** >>> >>> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >>> >>> (m3gdb) bt >>> #0 0x00d54402 in ?? () >>> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >>> #2 0x430c94b1 in abort () from /lib/libc.so.6 >>> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >>> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >>> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >>> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >>> msgA=16_00ed8ee8, >>> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >>> #7 0x00e9f212 in Crash (a= >>> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >>> `compiler_kind != ck_pm3' failed. >>> A problem internal to GDB has been detected, >>> further debugging may prove unreliable. >>> >>> I am using cvshead cm3, as of few days ago. >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From rodney.bates at wichita.edu Wed Aug 22 18:28:46 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 22 Aug 2007 11:28:46 -0500 Subject: [M3devel] A warning on dtoa.h Message-ID: <46CC643E.8000108@wichita.edu> I have located a case where dtoa.h (which is in libm3core) gives a wrong result when compiled by gcc 3.4.3 -O2 but works correctly with -O0. When compiled by gcc 4.1.1, this case works correctly with either optimization level. Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some "undefined" code remains to be seen. In either case, beware. It caused pm3 to miscompile the REAL constant 2.0, used in Table.mg, which made an instantiation of Table get a false runtime range error. It took days to track down. I had another instance of a bad real constant being compiled from a long time ago, that I never diagnosed. cm3 uses a virtually identical dtoa.h, and nothing in the call chain leading up to the instance where I found the problem is materially changed from pm3 to cm3, so probably cm3 is affected in the same way. -- ------------------------------------------------------------- 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 Wed Aug 22 19:34:00 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 13:34:00 -0400 Subject: [M3devel] A warning on dtoa.h In-Reply-To: <46CC643E.8000108@wichita.edu> References: <46CC643E.8000108@wichita.edu> Message-ID: Yes, I've been burned by this in the past too. For that reason, all my cm3.cfg files use -O in compile_c instead of -O3. I note that there is an updated dtoa, which perhaps we should be using instead, though I don't know if gcc optimizations still cause issues with it. I seem to recall it was something to do with aliasing, which gcc generates appropriate warnings for. I note that the newer dtoa requires some locking for preemptively- scheduled threads (as our later PTHREAD systems do), so perhaps some work is in order here. Here is the newer dtoa: -------------- next part -------------- A non-text attachment was scrubbed... Name: dtoa.c Type: application/octet-stream Size: 67983 bytes Desc: not available URL: -------------- next part -------------- On Aug 22, 2007, at 12:28 PM, Rodney M. Bates wrote: > I have located a case where dtoa.h (which is in libm3core) gives a > wrong result when compiled by gcc 3.4.3 -O2 but works correctly > with -O0. When compiled by gcc 4.1.1, this case works correctly > with either optimization level. > > Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some > "undefined" code remains to be seen. > > In either case, beware. It caused pm3 to miscompile the REAL constant > 2.0, used in Table.mg, which made an instantiation of Table get a > false > runtime range error. It took days to track down. I had another > instance of a bad real constant being compiled from a long time ago, > that I never diagnosed. > > cm3 uses a virtually identical dtoa.h, and nothing in the call chain > leading up to the instance where I found the problem is materially > changed from pm3 to cm3, so probably cm3 is affected in the same > way. > -- > ------------------------------------------------------------- > 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 Wed Aug 22 19:52:41 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 13:52:41 -0400 Subject: [M3devel] dtoa Message-ID: <12EDDFD3-D0D0-4003-AD66-C44B23809132@cs.purdue.edu> Also, note that since dtoa.h only implements strtod this may be the primary limitation on proper implementation of EXTENDED floating point (i.e., C long double). Currently, LONGREAL (C double) and EXTENDED are treated the same in CM3. Perhaps we should move to use of native strtold instead of the m3-strtod implemented in dtoa.h. From hosking at cs.purdue.edu Thu Aug 23 05:46:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 23:46:19 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: Message-ID: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> These will need more precise diagnosis. On Aug 22, 2007, at 11:28 PM, Alex Bochannek wrote: > I am building CVSup with the new CM3 and after applying the usual > patches plus the gettimeofday tz type patch, CVSup builds just fine on > Solaris 10. For testing purposes I am trying to get the cm3 repository > and am running into odd problems. > > o If I run the cvsup with the GUI, it shows up, I push the green arrow > and it immediately see "Cannot connect .... Error 0". I see a TCP > connection attempt, but it is being reset. > > o If I run it with -g -L 2, I get either: What do these flags do? The rest of your errors indicate something is terribly wrong with the threading subsystem. > > *** > *** runtime error: > *** Thread client error: Acquire of mutex already locked by self > *** file "ThreadPThread.m3", line 112 > *** This is a sanity check to make sure mutexes are not double-acquired. > > which is not reproducible but happens every once in a while, or: > > Updater failed: Cannot create directories leading to "/opt/cm3/ > cm3-cvs/sup/cm3/#cvs.cvsup-23065.0": Resource temporarily unavailable > > for every single subdirectory it needs to create. > > o If I create the subdirectories manually, the copies will start and I > eventually run into errors like the following ones for different > files: > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/runtime/common/RTType.m3", line 71 > *** One question: did you completely rebuild all the libraries? > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** > > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/runtime/common/RTCollector.m3", line 688 > *** Something very broken. Perhaps LockHeap is not functioning properly? > > or > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/FileStatus.m3", line 505 > *** Where is this module? > > or > > *** > *** runtime error: > *** Segmentation violation - possible attempt to dereference NIL > *** pc = 0x4619c8 = MyGetWideChars + 0x74 in ../src/text/ > TextSub.m3 > *** > > None of this happens with the EZM3 CVSup. The reason I am trying to do > all this, by the way is because I am looking at enhancing CVSup a > little > bit to get more information about repository structure and to also > resolve some issues I have seen with checksum errors. Learning > about the > CM3 environment in the process is interesting as well, of course. Hmm... How do we proceed in debugging this? > > Alex. > > P.S.: Not sure if this message makes it to m3devel. I don't think it > will since I read it through the Web site. From jdp at polstra.com Thu Aug 23 06:04:44 2007 From: jdp at polstra.com (John Polstra) Date: Wed, 22 Aug 2007 21:04:44 -0700 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> Message-ID: <46CD075C.7050001@polstra.com> Alex Bochannek wrote: > Tony Hosking writes: >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> This is a sanity check to make sure mutexes are not double-acquired. > > I suspect a race condition somewhere since it's not easily reproducible. Not many race conditions are possible in CVSup. It's multi-threaded, but the threads basically don't interact with each other and don't require locking against each other. It's more like a pipeline, with one thread feeding another thread, but virtually no interaction between threads otherwise. > >> One question: did you completely rebuild all the libraries? > > As far as I know. I'd be happy to do it again though. > >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> Where is this module? > > CVSup code in the suplib library. The relevant procedure starts out like > this: > > PROCEDURE WrPut(ww: WrWriter; fs: T) > RAISES {Error, Thread.Alerted, Wr.Failure} = > VAR > pcType: PathComp.Type; > pcName: TEXT; > dirUpAttr: FileAttr.T; > BEGIN > IF ww.cannotWrite THEN (* Don't even try. *) > RETURN; > END; > IF ww.current # NIL THEN (* Don't ever write the records out of order. *) > <* ASSERT Compare(ww.current, fs) < 0 *> > END; > ww.current := fs; Something's *really* screwed up. I've never in 10 years seen this assertion fail. John From dragisha at m3w.org Wed Aug 22 17:39:47 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 17:39:47 +0200 Subject: [M3devel] crashes everywhere In-Reply-To: <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> Message-ID: <1187797188.31487.113.camel@faramir.m3w.org> It is not... It was a bug I've explained in my replly to message you replied to... My code triggers it, but I suppose there is problem with CheckStoreTraced tracing through REF to C structure... Compiler did not complain, ot it did not generate correct info about "untracedness" of "REF to C structure"... I've fixed my code, but I do not think this (my message you replied show it) is correct way for CM3 to react to bug in code logic. dd On Wed, 2007-08-22 at 11:31 -0400, Tony Hosking wrote: > I can't speak for m3gdb, but something seems seriously wrong with > your installation. What program is causing this crash? Please also > tell me the version number of ThreadPThread.m3. The most recent > version is 1.48 of 2007-08-20. > > On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: > > > *** > > *** runtime error: > > *** An array subscript was out of range. > > *** file "../src/runtime/common/RTCollector.m3", line 2316 > > *** > > > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > > > (m3gdb) bt > > #0 0x00d54402 in ?? () > > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > > #2 0x430c94b1 in abort () from /lib/libc.so.6 > > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > > #7 0x00e9f212 in Crash (a= > > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > > `compiler_kind != ck_pm3' failed. > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > > > I am using cvshead cm3, as of few days ago. > > -- > > Dragi?a Duri? > -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Aug 23 16:27:15 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 10:27:15 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> Message-ID: You don't need m3gdb to get back traces. gdb works fine for that. On Aug 22, 2007, at 11:53 PM, Alex Bochannek wrote: > Tony Hosking writes: > >>> o If I run it with -g -L 2, I get either: >> >> What do these flags do? > > Sorry, those are CVSup client flags. No GUI (-g) and verbosity level 2 > (-L 2). > >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by >>> self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> >> This is a sanity check to make sure mutexes are not double-acquired. > > I suspect a race condition somewhere since it's not easily > reproducible. > >> One question: did you completely rebuild all the libraries? > > As far as I know. I'd be happy to do it again though. > >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> >> Where is this module? > > CVSup code in the suplib library. The relevant procedure starts out > like > this: > > PROCEDURE WrPut(ww: WrWriter; fs: T) > RAISES {Error, Thread.Alerted, Wr.Failure} = > VAR > pcType: PathComp.Type; > pcName: TEXT; > dirUpAttr: FileAttr.T; > BEGIN > IF ww.cannotWrite THEN (* Don't even try. *) > RETURN; > END; > IF ww.current # NIL THEN (* Don't ever write the records out > of order. *) > <* ASSERT Compare(ww.current, fs) < 0 *> > END; > ww.current := fs; > >> Hmm... How do we proceed in debugging this? > > If I had been able to build the m3gdb, maybe I could get backtraces > from > the core files? > > Alex. From hosking at cs.purdue.edu Thu Aug 23 16:29:39 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 10:29:39 -0400 Subject: [M3devel] CM3 d5.5.0 CVSup client issues. In-Reply-To: <1187849384.31487.139.camel@faramir.m3w.org> References: <10BA9907-E4B0-4DEA-A96C-82321B16CAF9@cs.purdue.edu> <1187849384.31487.139.camel@faramir.m3w.org> Message-ID: Sounds like I should do a build on my Solaris box and see if things work for me. On Aug 23, 2007, at 2:09 AM, Dragi?a Duri? wrote: > These'll need more errorprone instructions on install/upgrade, or more > reading of same :). This is kind of problems I've had when > something is > not built in correct order/not updated fully. > > I've build suplib & client moments ago and got this: > > faramir:dragisha/pts/15: src/cvsup-snap-16.1h/client% ./LINUXLIBC6/ > cvsup > -g ~/cvsupfile.cm3 > Connected to birch.elegosoft.com > Updating collection cm3/cvs > Updating collection cvsroot/cvs > Append to CVSROOT/history > Finished successfully > > I am not using suptcp, it's part of "patching" done for some earlier > cm3... Got this patch from this list, most probably. > > On Wed, 2007-08-22 at 23:46 -0400, Tony Hosking wrote: >> These will need more precise diagnosis. >> >> On Aug 22, 2007, at 11:28 PM, Alex Bochannek wrote: >> >>> I am building CVSup with the new CM3 and after applying the usual >>> patches plus the gettimeofday tz type patch, CVSup builds just >>> fine on >>> Solaris 10. For testing purposes I am trying to get the cm3 >>> repository >>> and am running into odd problems. >>> >>> o If I run the cvsup with the GUI, it shows up, I push the green >>> arrow >>> and it immediately see "Cannot connect .... Error 0". I see a TCP >>> connection attempt, but it is being reset. >>> >>> o If I run it with -g -L 2, I get either: >> >> What do these flags do? >> >> The rest of your errors indicate something is terribly wrong with the >> threading subsystem. >> >>> >>> *** >>> *** runtime error: >>> *** Thread client error: Acquire of mutex already locked by >>> self >>> *** file "ThreadPThread.m3", line 112 >>> *** >> >> This is a sanity check to make sure mutexes are not double-acquired. >> >>> >>> which is not reproducible but happens every once in a while, or: >>> >>> Updater failed: Cannot create directories leading to "/opt/cm3/ >>> cm3-cvs/sup/cm3/#cvs.cvsup-23065.0": Resource temporarily >>> unavailable >>> >>> for every single subdirectory it needs to create. >>> >>> o If I create the subdirectories manually, the copies will start >>> and I >>> eventually run into errors like the following ones for different >>> files: >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../src/runtime/common/RTType.m3", line 71 >>> *** >> >> One question: did you completely rebuild all the libraries? >> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 688 >>> *** >>> >>> >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/runtime/common/RTCollector.m3", line 688 >>> *** >> >> Something very broken. Perhaps LockHeap is not functioning properly? >> >>> >>> or >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/FileStatus.m3", line 505 >>> *** >> >> Where is this module? >> >>> >>> or >>> >>> *** >>> *** runtime error: >>> *** Segmentation violation - possible attempt to dereference >>> NIL >>> *** pc = 0x4619c8 = MyGetWideChars + 0x74 in ../src/text/ >>> TextSub.m3 >>> *** >>> >>> None of this happens with the EZM3 CVSup. The reason I am trying >>> to do >>> all this, by the way is because I am looking at enhancing CVSup a >>> little >>> bit to get more information about repository structure and to also >>> resolve some issues I have seen with checksum errors. Learning >>> about the >>> CM3 environment in the process is interesting as well, of course. >> >> Hmm... How do we proceed in debugging this? >> >>> >>> Alex. >>> >>> P.S.: Not sure if this message makes it to m3devel. I don't think it >>> will since I read it through the Web site. >> > -- > Dragi?a Duri? From rodney.bates at wichita.edu Fri Aug 24 02:21:32 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 23 Aug 2007 19:21:32 -0500 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: <46CE248C.6070702@wichita.edu> I just noticed that the failing code here looks a lot like the failure I traced to the dtoh problem. Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; > >>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > -- ------------------------------------------------------------- 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 Fri Aug 24 04:03:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 23 Aug 2007 22:03:56 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <46CE248C.6070702@wichita.edu> References: <1187611284.31487.42.camel@faramir.m3w.org> <46CE248C.6070702@wichita.edu> Message-ID: <69DE3922-2AA7-4446-8815-1D0BFD3C2D18@cs.purdue.edu> I tracked this one down to a problem with building m3cc on x86_64. It turns out (for reasons yet to be determined) that floating point constants get built wrong when m3cc is configured with CC="gcc -m32" that the problem goes away. This problem is internal to the gcc- based backend, so dtoa is not involved. On Aug 23, 2007, at 8:21 PM, Rodney M. Bates wrote: > I just noticed that the failing code here looks a lot like the failure > I traced to the dtoh problem. > > Dragi?a Duri? wrote: >> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >> (skipping >> m3gdb, which I've reported earlier would not compile for me) I am >> getting this error when I try to rn one of programs that worked >> flawlessy few checkouts ago. >> *** >> *** runtime error: >> *** An enumeration or subrange value was out of range. >> *** file "../src/uid/Common/TimeStamp.m3", line 63 >> *** >> This is corresponding code: >> now := Time.Now() - epoch; >> >>> time := TRUNC(now); >> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >> LONGREAL), 8)); >> I've identified few other problems, but I suppose ther are all >> variations... >> > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Aug 26 14:22:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:22:17 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: still no int64/longint support, but there's another build in ~jkrell on m3.elegosoft.comanyone want to try it?Jay at jay-win8 ~$ find ../cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2./cm3-min-WIN32-NT386-d5.5.0.tar.bz2Jay at jay-win8 ~$ pwd/home/Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 26 14:25:26 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:25:26 +0000 Subject: [M3devel] webscape crash Message-ID: I can't seem to get the hang of any of the modula-3 gui apps. They all look a bit clunky and act wierd or don't do much. Probably QT or GTk or wxWindows "bindings" are in order.. (QT is my pick..)mentor doesn't do much.deckscape and webscape don't much.I was able to crash webscape pretty quickly.0:014> .lasteventLast event: 4c4.5c0: Access violation - code c0000005 (first chance) debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7)0:014> u .m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]:005610b4 8b5e00 mov ebx,dword ptr [esi]005610b7 8b5300 mov edx,dword ptr [ebx]005610ba 8955e0 mov dword ptr [ebp-20h],edx005610bd 8d7de8 lea edi,[ebp-18h]005610c0 57 push edi005610c1 56 push esi005610c2 83fa00 cmp edx,0005610c5 750a jne m3core!RTHooks__Concat+0x8d (005610d1)0:014> r esiesi=000000000:014> kChildEBP RetAddr0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ 173]0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97]0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41]0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271]0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 [WebVBT.m3 @ 182]0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225]0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124]0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 [ThreadWin32.m3 @ 583]0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a [ThreadWin32.m3 @ 548]WARNING: Stack unwind information not available. Following frames may be wrong.0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b40:014> |. 0 id: 4c4 create name: WebScape.exe0:014> _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 26 17:38:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Aug 2007 11:38:52 -0400 Subject: [M3devel] another m3 build for win32.. In-Reply-To: References: Message-ID: PS There is LONGINT support for NT386, but it is just 32-bit, not 64-bit, so no improvement over INTEGER. On Aug 26, 2007, at 8:22 AM, j k wrote: > still no int64/longint support, but there's another build in > ~jkrell on m3.elegosoft.com > > anyone want to try it? > > Jay at jay-win8 ~ > $ find . > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Jay at jay-win8 ~ > $ pwd > /home/Jay > > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From hosking at cs.purdue.edu Sun Aug 26 17:40:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Aug 2007 11:40:08 -0400 Subject: [M3devel] webscape crash In-Reply-To: References: Message-ID: <8D17B1B0-54D5-4AAF-ABCE-0DBEB510CD38@cs.purdue.edu> Yikes, that seems like a problem since this is supposed to be builtin string concatenation. On Aug 26, 2007, at 8:25 AM, j k wrote: > I can't seem to get the hang of any of the modula-3 gui apps. They > all look a bit clunky and act wierd or don't do much. Probably QT > or GTk or wxWindows "bindings" are in order.. (QT is my pick..) > mentor doesn't do much. > deckscape and webscape don't much. > I was able to crash webscape pretty quickly. > > 0:014> .lastevent > Last event: 4c4.5c0: Access violation - code c0000005 (first chance) > debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7) > 0:014> u . > m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]: > 005610b4 8b5e00 mov ebx,dword ptr [esi] > 005610b7 8b5300 mov edx,dword ptr [ebx] > 005610ba 8955e0 mov dword ptr [ebp-20h],edx > 005610bd 8d7de8 lea edi,[ebp-18h] > 005610c0 57 push edi > 005610c1 56 push esi > 005610c2 83fa00 cmp edx,0 > 005610c5 750a jne m3core!RTHooks__Concat+0x8d > (005610d1) > 0:014> r esi > esi=00000000 > 0:014> k > ChildEBP RetAddr > 0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27] > 0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ > 173] > 0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97] > 0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41] > 0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271] > 0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 > [WebVBT.m3 @ 182] > 0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225] > 0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124] > 0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 > [ThreadWin32.m3 @ 583] > 0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a > [ThreadWin32.m3 @ 548] > WARNING: Stack unwind information not available. Following frames > may be wrong. > 0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b4 > 0:014> | > . 0 id: 4c4 create name: WebScape.exe > 0:014> > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Mon Aug 27 03:18:43 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 01:18:43 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: details.. :) > From: hosking at cs.purdue.edu> Date: Sun, 26 Aug 2007 11:38:52 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > PS There is LONGINT support for NT386, but it is just 32-bit, not > 64-bit, so no improvement over INTEGER.> > > On Aug 26, 2007, at 8:22 AM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 27 03:55:36 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 26 Aug 2007 21:55:36 -0400 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: <46D1F6E3.1E75.00D7.1@scires.com> Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 07:30:05 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 05:30:05 +0000 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: Randy, This is good to hear. Btw, there is no guaranteed of short names being available. You can do: fsutil behavior set disable8dot3 1 Btw, short names can be longer than long names, but true they can't have spaces. What a hack..C:\>mkdir \1.1.1 C:\>dir /x /ad 1*08/26/2007 10:10 PM 112E5D~1.1 1.1.1 The notion of passing a run of strings on a flat command line string with spaces between them when the items can have spaces in the first place is obviously broken. You can play with quoting, but then it's a never ending cycle of guessing how many times the quotes are going to be processed and with which rules. The right way to pass an array of strings around is to actually pass an array of strings.. Oh well.. Still I guess changing cm3 to try to use them in some cases might be a reasonable idea. I guess nobody cares on Unix about the spaces? I don't have any spaces, like in running the compiler or linker because 1) I install to \msdev\, none of the \program files places 2) by depending on %path% search. The current source does build with the latest released binaries, if you build in the right order and such. cm3\scripts\win\make-dist.cmd works. Somewhat precisely, from memory, you can do like: rmdir /q/s \cm3 extract latest distribution to \cm3 -- the system.tgz file. You don't need to run the cminstall.exe. cvs checkout to \dev2\cm3 copy \dev2\cm3\m3-sys\cminstall\src\config\nt386 \cm3\bin\cm3.cfg You don't need to edit the file at all, you just need %PATH%, %INCLUDE%, and %LIB% set. There are tradeoffs either way. This lets you changed Visual C++ toolsets by starting a new cmd and running another vcvars32.bat, instead of using a different cm3 configuration file. set some environment variables, mainly put cm3.exe in %PATH% and run the vcvars32.bat or such that Visual C++ includes, or start the Visual C++ command prompt from the start menu. cd \dev2\cm3\scripts\win .\make-dist This will give you something like (it will tell you exactly) %temp%\cm3\\cm3-5.5.0-min.tar.bz2 rmdir /q/s \cm3 extract the cm3-5.5.0-min.tar.bz2 to \cm3 If folks wants a .zip or a self expanding .zip, that is easily done. Tar.bz2 is reliably significantly smaller. Again cd to \dev2\cm3\scripts\win and run make-dist, or better yet do-cm3-std realclean and do-cm3-std buildship. As to the actual stability, I can't say. It is enough to build itself and then use that to build more stuff. I'm afraid I haven't looked at the cm3 gui stuff much. It seems very clunky. I guess we'll have to debug or compare the old and new source. I do remember seeing some questionable commits, like claims that Windows behavior had changed or that the author didn't know what was going but that some strange thing seemed to help. Windows really has a huge compatibility burden and the comments I thought were suspicous. Something around processing keystrokes and something around the environment variables passed to main. 4.1 is the old latest commercial release?I have that. I doubt it will build the current source. There is a file describing how to bootstrap from the older 3.6 release I think. I have not tried that. I believe WIDETEXT and WIDECHAR and such cause problems. Perhaps the compiler should use a strict subset of Modula-3 buildable with particular releases? The problem is probably a blurry line between compiler and runtime and the need to actually implement new features causing some circular dependency?? That's excellent about getting more of the source released. I had no idea what that would take. > same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP) Do folks still care about Win9x? 95? VC 8.0 binaries do not work on 95 for small reasons like use of IsDebuggerPresent and InterlockedCompareExchange. These are easily worked around if folks desire, or use an older toolset. (I didn't find Reactor all that impressive but ok. It is nice to hyperlink all the source, but it was hardly an IDE.) - Jay Date: Sun, 26 Aug 2007 21:55:36 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] cm3 on Windows, plus "Reactor" sources Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSPSenior Systems Engineer, Communications, Networks, & Electronics Division (CNE)Corporate & Atlanta Information Systems Security Manager (ISSM)Scientific Research Corporation2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Aug 27 07:39:14 2007 From: darko at darko.org (Darko) Date: Mon, 27 Aug 2007 07:39:14 +0200 Subject: [M3devel] another m3 build for win32.. In-Reply-To: References: Message-ID: I'm interested, but what windows tools does it require? On 26/08/2007, at 2:22 PM, j k wrote: > still no int64/longint support, but there's another build in > ~jkrell on m3.elegosoft.com > > anyone want to try it? > > Jay at jay-win8 ~ > $ find . > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Jay at jay-win8 ~ > $ pwd > /home/Jay > > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Mon Aug 27 09:04:53 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:04:53 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: simple answer and sufficient: "free" Visual C++ 8.0 compiler and linker search the web for "visual C++ express edition" => http://msdn2.microsoft.com/en-us/express/aa700735.aspx You don't need the IDE, so I don't /think/ you have to "register". Once you install it, the shortcut on the start menu to a cmd with some environment variables set is useful. I wrap it up in my own "environment" .cmd files, like \env\ms\vc80.bat and \env\cm3.vc80.bat (which uses \env\cm3.bat) TBD making these available to folks. They aren't quite generic but they are somewhat. The redist. Search the web for "Visual C++ redist" or "vcredist_X86.exe" => http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en or search for "vcredist_X86.exe sp1" or => http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en probably a Windows Platform SDK, not sure (and certainly not with the non-free Visual C++) search the web for "Windows Platform SDK" => http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en or => http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en I'm not even sure this is needed. Pretty much version will do, probably even the non-Microsoft ones such as ship with Mingwin/cygwin/openwatcom. The dependencies are fairly light, the Modula-3 system tries to be fairly self contained. more generally: I did some testing and applied some fixes with a range of toolsets: Visual C++ 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0. They should all work. You can get any of them from www.ebay.com. 7.1 used to be a free download. There is a beta out of 9.0 already. The binaries where built with 8.0 and so don't work on Windows 95 and require the redist. If folks really don't like that, there are alternatives, such as using libcmt.lib or using older toolsets, but using 8.0 and the redist and dropping Windows 95 seems very reasonable. I am /somewhat/ interested in adding support for other toolsets, like maybe www.openwatcom.com.And/or heck finish the work in CM3 on cutting the linker dependency, either write a linker in Modula-3 or load up the .objs at runtime. Oh, and tar and bzip2. I use the Cygwin versions. tar accepts the "j" flag to decompress bzip2. so like: rmdir /q/s \cm3 mkdir \cm3 cd \cm3 tar tjvz foo.tar.bz2 add \cm3\bin to %PATH% .tar.gz, .zip, self extracting .zip are all trivial to provide if tar/bzip2 is really an onerous dependency. .tar.bz2 is consistently and significantly smaller. The "support", like all of 2 lines of code, is in cm3\scripts\win\make-dist.cmd. - Jay > From: darko at darko.org> Date: Mon, 27 Aug 2007 07:39:14 +0200> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > I'm interested, but what windows tools does it require?> > > On 26/08/2007, at 2:22 PM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:19:52 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:19:52 +0000 Subject: [M3devel] platform names? Message-ID: Anyone want to propose platform names? Adopt a "system" where "OS", toolset, runtime, processor, and/or pointer size are clear, or just keep using short CAPS informal non-systematic names? NT386Wat? NT386WAT?? <== seems most likely given the current short informal CAPS non-systematic pattern NT386WATCOM? NT386Watcom? NTx86Watcom? Win32-x86-watcom? win-x86-openwatom1.7? NTAMD64? <== seems most likely given the current short informal CAPS non-systematic pattern NTIA64? win64-amd64-msc? (msc -- toolset and runtim, vs. say GNU or Watcom) win-amd64-msc? (drop "64" in favor of architecture, leaving win-x86 ambiguous though -- win-286, win-386?) win16? win64? Or just win + architecture or nt + architecture? Way too ambiguous. There is IA64 and there was Alpha64. Consider there is also Windows CE. win-mips? win-powerpc? wince-powerpc?winnt-powerpc? msnt-powerpc? msce-powerpc? msce-arm? (msc -- "Microsoft C" -- toolset and runtime) I am not suggesting developering support for any of these mind you. Which reminds me -- most of the architectures are dead. Should they be deleted? Resusicated? Resusicated if gcc supports them? Do nothing? I know I know, 64 bit integer support on NT386 is the most important thing to do right now. - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Aug 7 23:49:23 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 07 Aug 2007 21:49:23 -0000 Subject: [M3devel] LONGINT Message-ID: Shortly I will be checking in compiler and run-time updates that enable the LONGINT type: 32 <= BITSIZE(INTEGER) <= BITSIZE(LONGINT) <= 64 Here are the changes to the language spec, in the form of context diffs to the updated reference manual, which is available at http:// www.cs.purdue.edu/~hosking/m3/reference/index.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diffs Type: application/octet-stream Size: 15769 bytes Desc: not available URL: -------------- next part -------------- I have gone for the minimalist approach to adding LONGINT to the language. In brief, LONGINT is a distinct ordinal type from INTEGER. Conversions can be performed using ORD and VAL. For LONGINT 'n', ORD(n) converts n to an INTEGER. For INTEGER 'n', VAL (n, LONGINT) converts n to a LONGINT. Implicitly, this means all enumerations have an underlying INTEGER representation. LONGINT subranges work as expected. Open arrays are indexed by INTEGER values. Fixed arrays can have an index type whose base type is LONGINT. The rest of the changes to the language spec flow from these fundamentals. From rcoleburn at scires.com Thu Aug 9 01:28:05 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 08 Aug 2007 23:28:05 -0000 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <46BA192B.1E75.00D7.1@scires.com> Rodney: I believe that on Windows (Win32) the implementation uses native OS threads. At least that is how it worked for cm v4.1. Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:07:37 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:07:37 -0000 Subject: [M3devel] compiling the C code as C++? Message-ID: I was going through diffs I had around. One set is mostly putting #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif around all the C code, and a little something for the K&R code. The point was to compile all the C code as C++. I assume I had it working but I'll have to get back up to speed to verify that. Thoughts? - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:27:27 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:27:27 -0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? Message-ID: I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really? Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some. Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history". All you need is the following: signed and unsigned integer types that are exactly 8 bits in size signed and unsigned integer types that are exactly 16 bits in size signed and unsigned integer types that are exactly 32 bits in size signed and unsigned integer types that are exactly 64 bits in size signed and unsigned integer types that are exactly the size of a pointer 10 integer types total, named something like: INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit: int => INT => INT_PTR unsigned => UINT => UINT_PTR DWORD => DWORD_PTR convert to the upper case types if not there, and append "_PTR" The existing types size_t and ptrdiff_t did change size. If someone really needed 32 bit types there, you'd have to change your code. Windows has more than that for historical and stylistics reasons -- upper case types, lowercase types, types that "favor" being unsigned int or unsigned long. Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary. C 9x adds in "fast" and "small" types types that are the smallest type that is at least a certain size, I think types that are the fastest type that are at least a certain size, I think the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out beyond necessity. Yeah, obviously, they seem like maybe you might want them, but it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient to use on all forseeable processors, since tons of code uses them, and people should not will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are mostly stupid these days and they very often should be widened, but folks can do that "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used. Why has this been so hard in Modula-3? Is it that "Word" is widely used and has been pointer sized? Or that INTEGER has been widely used and sometimes assumed to be pointer sized? Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but weren't done right and there is some legacy we are stuck with?? Do "subrange" types make it all confusing? Or merely the assignment rules among the non subrange integer types? I have not paid particularly close attention; it just has always surprised me that it was difficult to work out what to do. I guess it is all moot now, the issues have been worked out and the feature is there. Good. I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly abstracted C names "short", "int", "long" are a useful abstraction. I think you really want the 10 base types I first listed. btw, even the types that are same size as a pointer are overused in C/C++. You don't need them for as much pointer arithmetic as people use. You can use "char*" for that. They are useful for array indices though, the result of wcslen, sizeof(), etc. File sizes should always be UINT64.. - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 17:18:34 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 15:18:34 -0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <3AAAC6BE-6742-4B5C-882F-980D1DA39D00@darko.org> The point of M3 is not be different than some other language, the point is for it to be safe, and, as a side effect, easy to use. Making a language safe is hard becuase you have to consider every possible usage and outcome becuase the language guarantees that it will not produce an "unchecked" error for the safe subset of the language, that is, it will do something random no matter how use use the language. So we have to consider all changes very carefully. On 11/08/2007, at 4:26 PM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 19:07:12 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:07:12 -0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: I can build the compiler, but, youch, can't build m3core\long.m3: "..\src\word\Long.m3", line 11: Unknown type of size other than dword in movOp The x86 back end needs work..I'll see if I can't just provide this stuff in C and avoid understanding the backend much.. - Jay> From: hosking at cs.purdue.edu> Date: Wed, 8 Aug 2007 08:39:34 -0400> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > Make sure to start with clean build directories and clean before > building with the bootstrapped compiler...> > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote:> > > Amended bootstrap instructions:> >> > Compiler and runtime extensions to support LONGINT type.> > > > Bootstrapping instructions: build and ship packages in the > > following order> > > > m3cc> > m3middle> > m3linker> > m3front> > m3quake> > cm3> > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> > > > Use this new compiler to build and ship the new system:> > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> > cd cm3/scripts> > ./do-cm3-std.sh realclean> > > ./do-cm3-std.sh buildship> > > > If this is successful then move the new compiler to BINDIR:> > > > mv $CM3 INSTALL_DIR/bin/cm3> >> > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: hosking at birch. 07/08/08 05:50:13> >>> >> Modified files:> >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html> >> for.html index.html m3.html m3index.html> >> numbers.html ordinal.html subtypes.html> >> typeops.html word-intf.html> >> cm3/m3-db/smalldb/src/: OSSupport.m3> >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3> >> SocketPosix.m3> >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3> >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c> >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3> >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3> >> cm3/m3-libs/m3core/src/thread/: m3makefile> >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3> >> Utypes.i3> >> m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/word/: m3makefile> >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> cm3/m3-sys/m3front/src/: m3makefile> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3> >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3> >> Dec.m3 First.m3 Floatt.m3> >> Floor.m3 Inc.m3 Last.m3> >> Max.m3 New.m3 Number.m3> >> Ord.m3 Round.m3 Subarray.m3> >> Trunc.m3 Val.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3> >> m3makefile> >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3> >> WordInsert.m3 WordModule.m3> >> WordNot.m3 WordOr.m3> >> WordRotate.m3 WordShift.m3> >> WordXor.m3> >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3> >> CastExpr.m3 CheckExpr.m3> >> CompareExpr.m3 DivExpr.m3> >> EqualExpr.m3 Expr.m3 ExprParse.m3> >> InExpr.m3 IntegerExpr.i3> >> IntegerExpr.m3 ModExpr.m3> >> MultiplyExpr.m3 NegateExpr.m3> >> ReelExpr.i3 ReelExpr.m3> >> SetExpr.m3 SubscriptExpr.m3> >> SubtractExpr.m3> >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3> >> Marker.m3 Scanner.m3 TipeDesc.i3> >> TipeDesc.m3 Token.i3 Token.m3> >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3> >> ForStmt.m3 TryFinStmt.m3> >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3> >> OpenArrayType.m3 SubrangeType.m3> >> Type.i3 Type.m3> >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3> >> Module.m3 Variable.m3> >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3> >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3> >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3> >> TWord.i3 TWord.m3 Target.i3 Target.m3> >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3> >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3> >> M3Lexer.m3 M3Type.i3 M3Type.m3> >> cm3/m3-tools/m3browser/src/: Main.m3> >> Added files:> >> cm3/doc/reference/: m3logo.gif> >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3> >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3> >> LongDivide.i3 LongDivide.m3> >> LongExtract.i3> >> LongExtract.m3 LongGE.i3> >> LongGE.m3 LongGT.i3> >> LongGT.m3 LongInsert.i3> >> LongInsert.m3 LongLE.i3> >> LongLE.m3 LongLT.i3> >> LongLT.m3 LongMinus.i3> >> LongMinus.m3 LongMod.i3> >> LongMod.m3 LongModule.i3> >> LongModule.m3 LongNot.i3> >> LongNot.m3 LongOr.i3> >> LongOr.m3 LongPlus.i3> >> LongPlus.m3 LongRotate.i3> >> LongRotate.m3 LongShift.i3> >> LongShift.m3 LongTimes.i3> >> LongTimes.m3 LongXor.i3> >> LongXor.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3> >>> >> Log message:> >> Compiler and runtime extensions to support LONGINT type.> >> > >> Bootstrapping instructions: build and ship packages in the > >> following order> >> > >> m3middle> >> m3linker> >> m3front> >> m3quake> >> cm3> >> > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> >> > >> Use this new compiler to build and ship the new system:> >> > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> >> cd cm3/scripts> >> ./do-cm3-std.sh buildship> >> > >> If this is successful then move the new compiler to BINDIR:> >> > >> mv $CM3 INSTALL_DIR/bin/cm3> >> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:53:11 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:53:11 -0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Ok, other than calling it "the x86 backend", I think I'm right. I wasn't sure if it was for all x86 platforms or just Windows.How about the "non gcc" backend? I think only Windows uses it and no other platform.I can get much further still having fixed BuildStandalone functionality in m3-sys\cminstall\src\config\NT386. I broke it a few months ago. I got as far as m3ui and something with RTHeapDep, I think the problem there is the interface got deleted between the last binary distribution and now. I'll dig a bit more.After fixing BuildStandalone, tried again with the inline Long.m3 and got the same errors so I put back my C implementation -- I am NOT sure it is right, either in calling convention or in implementing the shift/rotate/extract/insert stuff correctly.Now cm3 -ship works on m3core.dll as well but that's a different point. - JayFrom: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Sat, 11 Aug 2007 17:55:06 +0000Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> New home for Mom, no cleanup required. All starts here. _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:55:40 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:55:40 -0000 Subject: [M3devel] missing commits Message-ID: fyi, I'm not seeing my commits, probably my fault with my screwy-for-months-now mail configuration. I do intend to fix it soon... - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 22:16:36 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 20:16:36 -0000 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> The last commit I got was beginning of April. I think there might be a wider problem. On 11/08/2007, at 8:54 PM, j k wrote: > fyi, I'm not seeing my commits, probably my fault with my screwy- > for-months-now mail configuration. I do intend to fix it soon... > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 07:24:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 05:24:17 -0000 Subject: [M3devel] missing commits Message-ID: I am getting Tony's .tex commits, but didn't see mine.I say this half to cover my butt -- I made some commits.If I'm not seeing them, others maybe aren't either.I added a C version of Long.m3 for Win32.Not sure it is right, in a few ways. How it uses the stack. If it shifts and all by the right amounts? (n or 64 - n?) It definitely lets the build progress further. Surely it isn't ideal -- the C code actually generates calls out to the C runtime even, under the covers, so what was meant to be inlined is a two deep call tree! (The compiler generates the calls.)I fixed cminstall/src/config/NT386 so BuildStandalone works.I fixed scripts/win/clearenv.cmd so the user can set CM3 as per Tony's bootstrap instructions.Maybe others, don't recall.Nothing large.I figure I'll remove a bunch of extra semicolons in some C code.Any thoughts on the #ifdef __cplusplus extern "C" in C code? - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 19:01:40 -0400> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > I know there was a problem with the mailing list and I ended up re- > subscribing using my CVS username from the elegosoft web-site. It > seems that commits via CVS accounts pipe to the mailing list, but you > need to be subscribed with that id.> > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > > The last commit I got was beginning of April. I think there might > > be a wider problem.> >> >> > On 11/08/2007, at 8:54 PM, j k wrote:> >> >> fyi, I'm not seeing my commits, probably my fault with my screwy- > >> for-months-now mail configuration. I do intend to fix it soon...> >>> >> - Jay> >>> >> Recharge--play some free games. Win cool prizes too! Play It!> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:20:20 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:20:20 -0000 Subject: [M3devel] missing commits Message-ID: Because it doesn't work currently. This was easier but I agree not ideal. - Jay> From: hosking at cs.purdue.edu> Date: Sun, 12 Aug 2007 04:16:22 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > Why do you need a C version of Long.m3 for Win32? These operations > are built into the front-end, making use of backend functionality.> > On Aug 12, 2007, at 1:24 AM, j k wrote:> > > I am getting Tony's .tex commits, but didn't see mine.> > I say this half to cover my butt -- I made some commits.> > If I'm not seeing them, others maybe aren't either.> >> > I added a C version of Long.m3 for Win32.> > Not sure it is right, in a few ways.> > How it uses the stack.> > If it shifts and all by the right amounts? (n or 64 - n?)> > It definitely lets the build progress further.> > Surely it isn't ideal -- the C code actually generates> > calls out to the C runtime even, under the covers, so what> > was meant to be inlined is a two deep call tree!> > (The compiler generates the calls.)> >> > I fixed cminstall/src/config/NT386 so BuildStandalone works.> >> > I fixed scripts/win/clearenv.cmd so the user> > can set CM3 as per Tony's bootstrap instructions.> >> > Maybe others, don't recall.> > Nothing large.> >> > I figure I'll remove a bunch of extra semicolons in some C code.> >> > Any thoughts on the #ifdef __cplusplus extern "C" in C code?> >> > - Jay> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 11 Aug 2007 19:01:40 -0400> > > To: darko at darko.org> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] missing commits> > >> > > I know there was a problem with the mailing list and I ended up re-> > > subscribing using my CVS username from the elegosoft web-site. It> > > seems that commits via CVS accounts pipe to the mailing list, but > > you> > > need to be subscribed with that id.> > >> > > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > >> > > > The last commit I got was beginning of April. I think there might> > > > be a wider problem.> > > >> > > >> > > > On 11/08/2007, at 8:54 PM, j k wrote:> > > >> > > >> fyi, I'm not seeing my commits, probably my fault with my screwy-> > > >> for-months-now mail configuration. I do intend to fix it soon...> > > >>> > > >> - Jay> > > >>> > > >> Recharge--play some free games. Win cool prizes too! Play It!> > > >> > >> >> > See what you?re getting into?before you go there See it!> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:27:15 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:27:15 -0000 Subject: [M3devel] new Win32 build from current source Message-ID: Can folks try this? Make it available on the web page?There hasn't been a win32 release for longer than other platforms.I can build "core" and "std" if folks want.These files are directly output from scripts\win\make-dist.cmd. It has the support for "core" and "std", commented out. If folks prefer, tar.gz, .zip, and self extracting .zip are possible; .bz2 is smallest. Perhaps a version number should be in the .tar path structure? The install instructions are like (no cminstall, replaced by using vcvars32.bat which lets one CM3 install move among different tools, debatable which is better) cd /d c:\ optionally rmdir /q/s cm3 tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 run the usual vcvars32.bat or whatever (or use the start menu link that Visual C++ setup creates) set PATH=c:\cm3\bin;%PATH% set LIB=c:\cm3\lib;%lib% optionally, a good test: cd \scripts\win .\do-pkg-std realclean .\do-pkg-std buildship I have not tested the longint stuff and it likely doesn't work yet. The files are in ~jkrell on m3.elegosoft.com: C:\>ssh jkrell at m3.elegosoft.com find . ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 Remember you will need http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 or I could build it with an older toolset if folks want. Thanks, - Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:39:41 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:39:41 -0000 Subject: [M3devel] Some random notes on building/running Modula-3 on Windows (XP). Message-ID: Some of this is redundant -- i.e. has long been working. Some of it is specific to my configuration and habits. You are expected to recognize that. :) I am running Windows XP and currently using Visual C++ 8.0, though many versions of NT and VC should work. Some work has been put into ensuring multiple versions of VC work. Checkout the latest source. Really the latest. (at least of August 12 11am Pacific time). Download and extract the "latest" binary distribution, it is old but ok: cm3-min-WIN32-NT386-5.2.6.tar.bz2 Or maybe it was .gz, I always change them to save space. For me it is at C:\net\modula3\cm3-min-WIN32-NT386-5.2.6.tar.bz2 I install to the default c:\cm3. Prior to running cminstall, mkdir c:\cm3\t. Whenever cminstall asks for a path to a directory, just say c:\cm3\t. (It insists on an existing path, but with my configuration file, which is generic and checked in, none of them are used.) None of these paths matters if you do things this way. After running cminstall, you may rmdir the empty c:\cm3\t. Replace c:\cm3\bin\cm3.cfg with the latest source's cm3\m3-sys\cminstall\src\config\NT386. No edits are necessary. Or, if doing this repeatedly, I have it like so: cm3-min-WIN32-NT386-5.2.6.tar.bz2 is extracted to \net\modula3\cm3-min-WIN32-NT386-5.2.6\t and modified: delete bin\cm3.cfg delete bin\cm3.cfg--default and then to restore just: xcopy /fiveryh \net\modula3\cm3-min-WIN32-NT386-5.2.6\t \cm3 You need /h for hidden because tar will hide files like .M3EXPORTS that start with a dot. t for temp Setup your Visual C++ environment (%PATH%, %LIB%, %INCLUD%) by running the usual vcvars32.bat. For me this is running \env\cm3.vc80.bat (also have \env\cm3.vc20.bat, 40, 41, 42, 50, 60, 70, 71) set LIB=c:\cm3\lib;%LIB% set PATH=c:\cm3\bin;%PATH% Given the source tree at \dev2\cm3.2 I use \dev2 since Unix "takes" \dev. cm3.2 is because cm3 is an older tree I need to get the diffs out of and delete. These instructions are based on Tony's and very similar. Mainly that Windows does not use gcc. cd \dev2\cm3.2\scripts\win @rem make sure %CM3% is clear, in case of running through this stuff multiple times. set CM3= .\do-pkg realclean import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 .\do-pkg buildship import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 set CM3=C:\dev2\cm3.2\m3-sys\cm3\NT386\cm3.exe .\do-cm3-std realclean .\do-cm3-std buildship .\install-cm3-compiler upgrade Alternatively: extract/install/configure latest distribution as above checkout latest source cd scripts\win .\make-dist This gives you: cm3-min-WIN32-NT386-d5.3.2.tar.bz2 cm3-min-WIN32-NT386-d5.3.2-symbols.tar.bz2 buried in temp. I have not tested the new LONGINT functionality and there's a good chance it doesn't work yet. Various GUI apps start up ok. formsedit starts up and show gui. juno starts and shows gui, but crashes easily: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x5aaf8f8 0xf4fc2c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x5aafd54 0xf4db55 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... vorun brings up gui visobliq brings up gui not sure how to exit, had to kill it shownew brings up gui showheap brings up gui showthread brings up gui - Jay _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Mon Aug 13 21:49:17 2007 From: stsp at elego.de (Stefan Sperling) Date: Mon, 13 Aug 2007 19:49:17 -0000 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813143915.71BE510D4363@birch.elegosoft.com> References: <20070813143915.71BE510D4363@birch.elegosoft.com> Message-ID: <20070813194447.GE1351@ted.stsp.lan> On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 07/08/13 16:39:15 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c > > Log message: > No change to the contents of these files. This is an attempt to get > the time stampof ada-lex.c to be later than that of ada-lex.l. This > will mean m3gdb will build without requiring flex to be installed. What about hacking a 'touch ada-lex.c' into the Makefile somewhere instead? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 12:40:56 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 10:40:56 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: <20070816102225.GA25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? Current head, 5.4, or both? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 13:10:49 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 11:10:49 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816102225.GA25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> Message-ID: <20070816105922.GB25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > > Stefan, could you add the --disable-nls to the gcc configuration and > > try to build a SOLgnu archive? > > Current head, 5.4, or both? Wait a minute... as far as I can tell we already build it with --disable-nls in all cases. Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk has the same): % configure the sources if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "--with-gnu-ld=yes", "&& echo \"done\" > " & done) else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--target=" & GNU_platform (M3CC_TARGET), "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end end -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 16:08:12 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 14:08:12 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> Message-ID: <20070816134458.GD25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 02:54:34PM +0200, Olaf Wagner wrote: > Then I don't understand why the version Alex Bochannek got from > our installation archives needed libiconv.so.2. Any idea? Because m3-sys/m3cc/gcc/gcc/configure.ac depends on it unconditionally. The following is in global scope: AM_ICONV # Until we have in-tree GNU iconv: LIBICONV_DEP= AC_SUBST(LIBICONV_DEP) So I guess the configure script always picks up libiconv if it is present. I'll try to remove the check for libiconv to see if the backend builds without it. The script even bothers to filter out possible multiple occurences of -liconv if --enable-nls is passed (i.e. gcc if is linked to libintl): # If LIBINTL contains LIBICONV, then clear LIBICONV so we don't get # -liconv on the link line twice. case "$LIBINTL" in *$LIBICONV*) LIBICONV= ;; esac The non-iconv case is clearly not intended by the authors of configure.ac... Also, I just checked the cm3cg binary on FreeBSD, it also depends on libiconv, which is not in the base system on FreeBSD either: % ldd /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg: libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28474000) libc.so.6 => /lib/libc.so.6 (0x28561000) -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:32:46 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:32:46 -0000 Subject: [M3devel] AMD64 In-Reply-To: References: Message-ID: <20070816172515.GC15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:32:46 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:32:46 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816171813.GB15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:47:18 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:47:18 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816174655.GD15579@jack.stsp.lan> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. I'd favour listing libiconv as an explicit dependency of cm3. I've looked into this, and --disable-nls is not sufficient to remove gcc's dependency on libiconv. It unconditionally depends on libiconv if it can find the library on the system, regardless of flags passed to the configure script. I've tried hacking iconv detection out of the build system. There's a diff below against cm3-5.4 that removes cm3cg's dependency on libiconv. But it is very ugly. m3gdb also unconditionally depends on libiconv. I have not looked into that. I cannot deinstall libiconv on our Solaris box to prevent configure from picking it up because I don't have root, and I don't really think it's a good idea to begin with because removing the library would probably break a lot of dependencies. Alex, could you provide more details on what gcc backend you are using? Does the ezm3 equivalent of the cm3cg executable depend on libiconv? % ldd /usr/local/cm3/bin/cm3cg libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 With the patch below I get: % ldd /usr/stsp/cm3/bin/cm3cg libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 Index: src/m3makefile =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 m3makefile --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 @@ -126,7 +126,8 @@ if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." + & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", Index: gcc/gcc/Makefile.in =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 @@ -471,8 +471,8 @@ LIBINTL_DEP = @LIBINTL_DEP@ # Character encoding conversion library. -LIBICONV = @LIBICONV@ -LIBICONV_DEP = @LIBICONV_DEP@ +#LIBICONV = @LIBICONV@ +#LIBICONV_DEP = @LIBICONV_DEP@ # The GC method to be used on this system. GGC=@GGC at .o @@ -718,7 +718,7 @@ BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a # Dependencies on the intl and portability libraries. -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) # Likewise, for use in the tools that must run on this machine # even if we are cross-building GCC. @@ -726,7 +726,7 @@ # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:50:37 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 17:50:37 -0000 Subject: [M3devel] AMD64 In-Reply-To: <20070816172515.GC15579@jack.stsp.lan> References: <20070816172515.GC15579@jack.stsp.lan> Message-ID: <20070816174956.GE15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 07:25:15PM +0200, Stefan Sperling wrote: > <<< No Message Collected >>> > --oTHb8nViIGeoXxdp-- Sorry, local sendmail screw up. Manually messing with the mail queue is not a good idea :-/ Here is the message again: On Thu, Aug 16, 2007 at 01:13:06PM -0400, Tony Hosking wrote: > I seem to recall that someone had been working on a Linux AMD64 target. > I'd like to get that working and would be interested in any progress that's > been made in that direction. That was me. It was more than 2 years ago. The problem back then was that the gcc backend kept segfaulting while trying to bootstrap a native cm3 for amd64. The front end is pretty much done iirc. We anticipated an update of the backend to see if that would fix things. Since you've done the update long ago at this stage, I guess it's worth trying to merge the diff into the current tree, minus the now obsolete system call wrappers in the diff. Maybe things just work. The diff is here: http://www.stsp.name/cm3/cm3-linux-amd64-2005-04-18.patch -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:08:13 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 18:08:13 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816175930.GG15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... Is that because you don't have libiconv installed on your system? -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:10:45 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 18:10:45 -0000 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816181004.GH15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:54:55PM -0400, Tony Hosking wrote: > PS Here is how I configured building in m3cc/SOLgnu: > > ../gcc/configure --enable-languages=m3cg --disable-nls --disable-nls makes no difference at all with respect to libiconv. See my previous mail. All --disable-nls does is remove a dependency on libintl. This is not a Solaris-only problem. We can either: 1) Build cm3 releases on boxes that haven't got libiconv installed. 2) Declare libiconv an official dependency of cm3. 3) Hack the dependency on libiconv out of the build systems of cm3cg and m3gdb, and possibly others. 1) is a pain for people making releases. 2) is easy for developers, and nothing changes for users because we've always implicitly depended on libiconv without noticing. I've posted a crude patch that does 3) for cm3cg, but not for m3gdb. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Fri Aug 17 14:44:47 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 17 Aug 2007 12:44:47 -0000 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> Message-ID: <20070817121902.GB10092@jack.stsp.lan> On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: > Stefan, I thought we had resolved this issue at least for Linux and > Solaris setups with the last release. Did we miss something? We link system libraries dynamically on these platforms. It could be that Rodney's own program does not link libraries dynamically, so he gets the warning. This is the diff that introduced dynamic linking on Linux. Note that we explicitly enable dynamic linking on a per-library basis... maybe we should enforce dynamic linking in general? Index: LINUXLIBC6 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cm3/src/config/LINUXLIBC6,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- LINUXLIBC6 6 Aug 2006 12:46:03 -0000 1.7 +++ LINUXLIBC6 1 Sep 2006 13:42:23 -0000 1.8 @@ -98,14 +98,14 @@ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], -% "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms - "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], - "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], - "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], - "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], - "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", +% "LEX-YACC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-ll" ], %-- not on most Linux platforms + "FLEX-BISON" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lfl" ], + "POSTGRES95" : [ "-Xlinker", "-Bdynamic", "-L/usr/local/postgres95/lib", "-lpq" ], + "OPENGL" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], + "MOTIF" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXm" ], + "X11" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], - "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], + "PTHREAD" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rcoleburn at scires.com Fri Aug 17 23:26:31 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Aug 2007 21:26:31 -0000 Subject: [M3devel] A strange link time warning using cm3] In-Reply-To: <46C6045A.6050402@wichita.edu> References: <46C6045A.6050402@wichita.edu> Message-ID: <46C5DA31.1E75.00D7.1@scires.com> >>> "Rodney M. Bates" rodney.bates at wichita.edu> 8/17/2007 4:26 PM >> ( mailto:rodney.bates at wichita.edu> ) .... But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. .... I thought that the buildstandalone() directive in the m3makefile is supposed to cause linking with static libraries. At least that is what happens in cm3 v4.1. Regards, Randy Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 18 04:37:36 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 18 Aug 2007 02:37:36 -0000 Subject: [M3devel] Windows Message-ID: I have the inclination, still working on time and expertise. :) Summarize the layering for me? Which module calls which?Your mention below of the assumption of 32 bit ops at least confirms what I thought I vaguely understood reading through the source. It's just a bunch of pretty dense code without documentation, the sort I write myself when I have the whole program in my head and just need to type it all in as quickly as possible. Would the idea be to use a tagged union for this stack, or to split 64 bits ops into pairs of 32 bit ops? You know, like, does this stack translate "closely" to the generated code, or not? If it does, pairs, if it does not, tagged union. Probably. Similarly, like, all the register dealings need some notion of pairs..? Maybe I should look at the other backend to understand better, if there is an analogous bunch of code. Anyway, I'll try at least this weekend to verify that it's buildable asis, i know that's just a teeny tiny baby step, just push the button to build, a monkey could do it... my expertise is beyond that, but... I suspect tagged union is it, and have to churn a bunch of code to check the type. ugh. lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 bit type). ?? Thanks, - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: Windows> Date: Thu, 16 Aug 2007 12:47:36 -0400> To: jay.krell at cornell.edu; jayk123 at hotmail.com> > I should have realized of course that there is a very simple fix for > compilation on the NT386 target using the native m3back backend! > Simply make LONGINT=Int32. Jay, I have just checked in this very > simple fix to Target.m3 which should permit you to bootstrap a new > cm3 and compile the current CVS head.> > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote:> > > With the current native Windows backend (m3back) blindly assuming > > (without even checking!) that all integer operations are 32-bit, I > > wonder if anyone out there has the expertise, time, or inclination > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > not be *too* hard, but I don't have the time for it now, though I > > would be happy to answer any questions that arise. Unfortunately, > > this reveals that Windows support is withering on the vine, in > > spite of Jay's excellent recent work. As of now, this means that > > Windows can only build CVS sources with the tag > > devel_LONGINT_start. Bridging the gap will require smartening up > > m3back or using the gcc-based backend.> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Aug 22 19:34:37 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 17:34:37 -0000 Subject: [M3devel] A warning on dtoa.h In-Reply-To: <46CC643E.8000108@wichita.edu> References: <46CC643E.8000108@wichita.edu> Message-ID: Yes, I've been burned by this in the past too. For that reason, all my cm3.cfg files use -O in compile_c instead of -O3. I note that there is an updated dtoa, which perhaps we should be using instead, though I don't know if gcc optimizations still cause issues with it. I seem to recall it was something to do with aliasing, which gcc generates appropriate warnings for. I note that the newer dtoa requires some locking for preemptively- scheduled threads (as our later PTHREAD systems do), so perhaps some work is in order here. Here is the newer dtoa: -------------- next part -------------- A non-text attachment was scrubbed... Name: dtoa.c Type: application/octet-stream Size: 67983 bytes Desc: not available URL: -------------- next part -------------- On Aug 22, 2007, at 12:28 PM, Rodney M. Bates wrote: > I have located a case where dtoa.h (which is in libm3core) gives a > wrong result when compiled by gcc 3.4.3 -O2 but works correctly > with -O0. When compiled by gcc 4.1.1, this case works correctly > with either optimization level. > > Whether this is a bug in gcc 3.4.3 -O2, or whether dtoa.h has some > "undefined" code remains to be seen. > > In either case, beware. It caused pm3 to miscompile the REAL constant > 2.0, used in Table.mg, which made an instantiation of Table get a > false > runtime range error. It took days to track down. I had another > instance of a bad real constant being compiled from a long time ago, > that I never diagnosed. > > cm3 uses a virtually identical dtoa.h, and nothing in the call chain > leading up to the instance where I found the problem is materially > changed from pm3 to cm3, so probably cm3 is affected in the same > way. > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From jayk123 at hotmail.com Sun Aug 26 14:22:17 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:22:17 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: still no int64/longint support, but there's another build in ~jkrell on m3.elegosoft.comanyone want to try it?Jay at jay-win8 ~$ find ../cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2./cm3-min-WIN32-NT386-d5.5.0.tar.bz2Jay at jay-win8 ~$ pwd/home/Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 26 14:25:26 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 26 Aug 2007 12:25:26 +0000 Subject: [M3devel] webscape crash Message-ID: I can't seem to get the hang of any of the modula-3 gui apps. They all look a bit clunky and act wierd or don't do much. Probably QT or GTk or wxWindows "bindings" are in order.. (QT is my pick..)mentor doesn't do much.deckscape and webscape don't much.I was able to crash webscape pretty quickly.0:014> .lasteventLast event: 4c4.5c0: Access violation - code c0000005 (first chance) debugger time: Sun Aug 26 05:19:29.046 2007 (GMT-7)0:014> u .m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]:005610b4 8b5e00 mov ebx,dword ptr [esi]005610b7 8b5300 mov edx,dword ptr [ebx]005610ba 8955e0 mov dword ptr [ebp-20h],edx005610bd 8d7de8 lea edi,[ebp-18h]005610c0 57 push edi005610c1 56 push esi005610c2 83fa00 cmp edx,0005610c5 750a jne m3core!RTHooks__Concat+0x8d (005610d1)0:014> r esiesi=000000000:014> kChildEBP RetAddr0683fbc8 10018884 m3core!RTHooks__Concat+0x70 [TextCat.m3 @ 27]0683fc0c 10018200 webvbt!SimpleWeb__Acceptable+0xa3 [SimpleWeb.m3 @ 173]0683fd10 10017d66 webvbt!SimpleWeb__DoFetch+0x48f [SimpleWeb.m3 @ 97]0683fd40 1001b47f webvbt!SimpleWeb__Fetch+0x28 [SimpleWeb.m3 @ 41]0683fd7c 1001ad7b webvbt!WebVBT__LoadResources+0xfe [WebVBT.m3 @ 271]0683fdcc 1001a289 webvbt!WebVBT__Display__NewHTMLPage+0x435 [WebVBT.m3 @ 182]0683feb4 1001a15a webvbt!WebVBT__Display+0x10e [WebVBT.m3 @ 225]0683ff50 00549d75 webvbt!WebVBT__FetchWrapper+0x19f [WebVBT.m3 @ 124]0683ff88 00549ae3 m3core!ThreadWin32__RunThread+0x221 [ThreadWin32.m3 @ 583]0683ffb4 7c80b683 m3core!ThreadWin32__ThreadBase+0x3a [ThreadWin32.m3 @ 548]WARNING: Stack unwind information not available. Following frames may be wrong.0683ffec 00000000 kernel32!GetModuleFileNameA+0x1b40:014> |. 0 id: 4c4 create name: WebScape.exe0:014> _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 03:18:43 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 01:18:43 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: details.. :) > From: hosking at cs.purdue.edu> Date: Sun, 26 Aug 2007 11:38:52 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > PS There is LONGINT support for NT386, but it is just 32-bit, not > 64-bit, so no improvement over INTEGER.> > > On Aug 26, 2007, at 8:22 AM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoleburn at scires.com Mon Aug 27 03:55:36 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Sun, 26 Aug 2007 21:55:36 -0400 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: <46D1F6E3.1E75.00D7.1@scires.com> Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 07:30:05 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 05:30:05 +0000 Subject: [M3devel] cm3 on Windows, plus "Reactor" sources Message-ID: Randy, This is good to hear. Btw, there is no guaranteed of short names being available. You can do: fsutil behavior set disable8dot3 1 Btw, short names can be longer than long names, but true they can't have spaces. What a hack..C:\>mkdir \1.1.1 C:\>dir /x /ad 1*08/26/2007 10:10 PM 112E5D~1.1 1.1.1 The notion of passing a run of strings on a flat command line string with spaces between them when the items can have spaces in the first place is obviously broken. You can play with quoting, but then it's a never ending cycle of guessing how many times the quotes are going to be processed and with which rules. The right way to pass an array of strings around is to actually pass an array of strings.. Oh well.. Still I guess changing cm3 to try to use them in some cases might be a reasonable idea. I guess nobody cares on Unix about the spaces? I don't have any spaces, like in running the compiler or linker because 1) I install to \msdev\, none of the \program files places 2) by depending on %path% search. The current source does build with the latest released binaries, if you build in the right order and such. cm3\scripts\win\make-dist.cmd works. Somewhat precisely, from memory, you can do like: rmdir /q/s \cm3 extract latest distribution to \cm3 -- the system.tgz file. You don't need to run the cminstall.exe. cvs checkout to \dev2\cm3 copy \dev2\cm3\m3-sys\cminstall\src\config\nt386 \cm3\bin\cm3.cfg You don't need to edit the file at all, you just need %PATH%, %INCLUDE%, and %LIB% set. There are tradeoffs either way. This lets you changed Visual C++ toolsets by starting a new cmd and running another vcvars32.bat, instead of using a different cm3 configuration file. set some environment variables, mainly put cm3.exe in %PATH% and run the vcvars32.bat or such that Visual C++ includes, or start the Visual C++ command prompt from the start menu. cd \dev2\cm3\scripts\win .\make-dist This will give you something like (it will tell you exactly) %temp%\cm3\\cm3-5.5.0-min.tar.bz2 rmdir /q/s \cm3 extract the cm3-5.5.0-min.tar.bz2 to \cm3 If folks wants a .zip or a self expanding .zip, that is easily done. Tar.bz2 is reliably significantly smaller. Again cd to \dev2\cm3\scripts\win and run make-dist, or better yet do-cm3-std realclean and do-cm3-std buildship. As to the actual stability, I can't say. It is enough to build itself and then use that to build more stuff. I'm afraid I haven't looked at the cm3 gui stuff much. It seems very clunky. I guess we'll have to debug or compare the old and new source. I do remember seeing some questionable commits, like claims that Windows behavior had changed or that the author didn't know what was going but that some strange thing seemed to help. Windows really has a huge compatibility burden and the comments I thought were suspicous. Something around processing keystrokes and something around the environment variables passed to main. 4.1 is the old latest commercial release?I have that. I doubt it will build the current source. There is a file describing how to bootstrap from the older 3.6 release I think. I have not tried that. I believe WIDETEXT and WIDECHAR and such cause problems. Perhaps the compiler should use a strict subset of Modula-3 buildable with particular releases? The problem is probably a blurry line between compiler and runtime and the need to actually implement new features causing some circular dependency?? That's excellent about getting more of the source released. I had no idea what that would take. > same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP) Do folks still care about Win9x? 95? VC 8.0 binaries do not work on 95 for small reasons like use of IsDebuggerPresent and InterlockedCompareExchange. These are easily worked around if folks desire, or use an older toolset. (I didn't find Reactor all that impressive but ok. It is nice to hyperlink all the source, but it was hardly an IDE.) - Jay Date: Sun, 26 Aug 2007 21:55:36 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.comSubject: [M3devel] cm3 on Windows, plus "Reactor" sources Hi Folks: Sorry for my long absence on the M3 development front. I've been watching with great interest the flurry of activity regarding 64-bit INTEGERS and the changes in the garbage collection, threading models, etc. I believe I am now in a position to begin doing a little more Modula-3 work from time to time. My primary environment currently is Windows XP. I have the old cm3 v4.1 system running on XP using Microsoft's free Visual Studio environment for the linking and the C/C++ compilation. My v4.1 system works with Trestle, FormsVBT, pickles, network objects, etc. It uses a native Win32 backend, not the GCC backend. I am able to deal with the embedded spaces in filenames by forcing everything to use Microsoft's short names for the non-8dot3 names (e.g., the names you get via the "dir /X" command). I have a number of multi-threaded programs I've developed over the years on the Windows platform, so as the cm3 community moves forward I will be happy to test the latest cm3 on the Windows XP platform using some of my old programs as tests. Most of the programs were developed for specific clients and thus can't be shared with the community, but they should provide a good set of test cases for the new cm3 because I've had most of these same programs operating on a variety of platforms, including Windows (98, NT, 2000, XP), HP-UX, and Solaris due to the platform-independence provided by cm3. I also have been working to make available the sources of Critical Mass Inc.'s "Reactor" integrated development environment. This environment provided for browsing of package repositories & documentation, building packages, running programs, creating new packages, etc. all from your favorite web browser. Due to various trademark concerns and legal issues, we can no longer use the name "Reactor," so I've taken the liberty of renaming the package "CM3-IDE." (If someone has a better name suggestion, let me know.) I am very close to having all the legal and other requirements worked out to make publication of the revised sources available to the cm3 community. I do need to test the revised sources using the latest cm3 environment. So, my immediate need is for a stable version of cm3 to run on Windows XP so that I can test the new CM3-IDE. Of course, CM3-IDE does work with my v4.1 system, but I had to make changes for the new cm3 version due to changes in TEXT, etc. I tried using a v5.2.6 edition of cm3, but ran into some problems with strange GUI behavior and problems with m3bundles. Since I have a stable v4.1 cm3 system, can I use it to bootstrap the latest cm3 edition? I would appreciate some guidance here on how to obtain the latest stable sources and get a working system on Windows XP. Regards, Randy Coleburn Randy C. Coleburn, CISSPSenior Systems Engineer, Communications, Networks, & Electronics Division (CNE)Corporate & Atlanta Information Systems Security Manager (ISSM)Scientific Research Corporation2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:04:53 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:04:53 +0000 Subject: [M3devel] another m3 build for win32.. Message-ID: simple answer and sufficient: "free" Visual C++ 8.0 compiler and linker search the web for "visual C++ express edition" => http://msdn2.microsoft.com/en-us/express/aa700735.aspx You don't need the IDE, so I don't /think/ you have to "register". Once you install it, the shortcut on the start menu to a cmd with some environment variables set is useful. I wrap it up in my own "environment" .cmd files, like \env\ms\vc80.bat and \env\cm3.vc80.bat (which uses \env\cm3.bat) TBD making these available to folks. They aren't quite generic but they are somewhat. The redist. Search the web for "Visual C++ redist" or "vcredist_X86.exe" => http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en or search for "vcredist_X86.exe sp1" or => http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en probably a Windows Platform SDK, not sure (and certainly not with the non-free Visual C++) search the web for "Windows Platform SDK" => http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en or => http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en I'm not even sure this is needed. Pretty much version will do, probably even the non-Microsoft ones such as ship with Mingwin/cygwin/openwatcom. The dependencies are fairly light, the Modula-3 system tries to be fairly self contained. more generally: I did some testing and applied some fixes with a range of toolsets: Visual C++ 2.0, 4.0, 4.1, 4.2, 5.0, 6.0, 7.0, 7.1, 8.0. They should all work. You can get any of them from www.ebay.com. 7.1 used to be a free download. There is a beta out of 9.0 already. The binaries where built with 8.0 and so don't work on Windows 95 and require the redist. If folks really don't like that, there are alternatives, such as using libcmt.lib or using older toolsets, but using 8.0 and the redist and dropping Windows 95 seems very reasonable. I am /somewhat/ interested in adding support for other toolsets, like maybe www.openwatcom.com.And/or heck finish the work in CM3 on cutting the linker dependency, either write a linker in Modula-3 or load up the .objs at runtime. Oh, and tar and bzip2. I use the Cygwin versions. tar accepts the "j" flag to decompress bzip2. so like: rmdir /q/s \cm3 mkdir \cm3 cd \cm3 tar tjvz foo.tar.bz2 add \cm3\bin to %PATH% .tar.gz, .zip, self extracting .zip are all trivial to provide if tar/bzip2 is really an onerous dependency. .tar.bz2 is consistently and significantly smaller. The "support", like all of 2 lines of code, is in cm3\scripts\win\make-dist.cmd. - Jay > From: darko at darko.org> Date: Mon, 27 Aug 2007 07:39:14 +0200> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] another m3 build for win32..> > I'm interested, but what windows tools does it require?> > > On 26/08/2007, at 2:22 PM, j k wrote:> > > still no int64/longint support, but there's another build in > > ~jkrell on m3.elegosoft.com> >> > anyone want to try it?> >> > Jay at jay-win8 ~> > $ find .> > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2> > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2> >> > Jay at jay-win8 ~> > $ pwd> > /home/Jay> >> >> > Find a local pizza place, movie theater, and more?.then map the > > best route! Find it!> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Aug 27 09:19:52 2007 From: jayk123 at hotmail.com (j k) Date: Mon, 27 Aug 2007 07:19:52 +0000 Subject: [M3devel] platform names? Message-ID: Anyone want to propose platform names? Adopt a "system" where "OS", toolset, runtime, processor, and/or pointer size are clear, or just keep using short CAPS informal non-systematic names? NT386Wat? NT386WAT?? <== seems most likely given the current short informal CAPS non-systematic pattern NT386WATCOM? NT386Watcom? NTx86Watcom? Win32-x86-watcom? win-x86-openwatom1.7? NTAMD64? <== seems most likely given the current short informal CAPS non-systematic pattern NTIA64? win64-amd64-msc? (msc -- toolset and runtim, vs. say GNU or Watcom) win-amd64-msc? (drop "64" in favor of architecture, leaving win-x86 ambiguous though -- win-286, win-386?) win16? win64? Or just win + architecture or nt + architecture? Way too ambiguous. There is IA64 and there was Alpha64. Consider there is also Windows CE. win-mips? win-powerpc? wince-powerpc?winnt-powerpc? msnt-powerpc? msce-powerpc? msce-arm? (msc -- "Microsoft C" -- toolset and runtime) I am not suggesting developering support for any of these mind you. Which reminds me -- most of the architectures are dead. Should they be deleted? Resusicated? Resusicated if gcc supports them? Do nothing? I know I know, 64 bit integer support on NT386 is the most important thing to do right now. - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 19:55:21 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:55:21 -0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Aug 3 01:35:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 2 Aug 2007 19:35:08 -0400 Subject: [M3devel] pthreads issues [was: Re: strange errors... ] In-Reply-To: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> References: <200707221212.l6MCC7OO073517@camembert.async.caltech.edu> Message-ID: <7AAE9AC9-2D63-49F6-8CB5-CD72E5EBF2FB@cs.purdue.edu> I'm pretty sure my latest checkins fix the remaining issues with pthread threading. Please let me know of any further problems. mentor now works reliably for me -- YAY! On Jul 22, 2007, at 8:12 AM, Mika Nystrom wrote: > > Tony Hosking writes: > ... >>> but after recompiling a second time, it no longer seems to do that. >>> By the way, I am somewhat suspicious that this Juno crash has >>> something to do with threading: if you look closely, that part of >>> Juno has to do with thread switching into and out of the >>> Juno-machine...which is why I was happy to see it disappear (however >>> it did that). >> >> Maybe you had stale code in the build directories? Glad to hear it >> went away after recompiling. >> > > I *obsessively* clean my directories between builds! I have double- > and triple-checked that nothing in the source tree is left in object > form after doing > > do-cm3-std.sh realclean > do-cm3-core.sh realclean > > Yet, this happens. My best guess is that somehow, old objects (from > /usr/local/cm3/pkg?) are "leaking" through the bootstrapping process. > Surely that's not supposed to happen? Why does it happen to me and > apparently not to you? I follow your directions exactly and always > start from an absolutely clean system (on Mac I don't even have PM3 > installed, so there's no Modula-3 at all before I start following > the instructions). > > >>> I still have a threading crash in mentor. I run "Wheeler" to get >>> this >>> one... >>> > ... >>> >>> *** >>> *** runtime error: >>> *** <*ASSERT*> failed. >>> *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 675 >>> *** >>> >> >> That is an assert regarding setting the stack size. I wonder if this >> is a Thread.SizedClosure which has a size value that asks for a stack >> size less than PTHREAD_STACK_MIN. I am not sure what the best way to >> handle that is except to disregard the return value from >> pthread_attr_setstacksize. Can you try replacing line 675 in >> ThreadPThread.m3 with: >> >> EVAL Upthread.attr_setstacksize(attr, bytes); >> >> and rebuilding? I am surprised to see that error though, since you >> will note that I get the default stack size from a freshly >> initialized attributes structure on line 673 and use the greater of >> the default size and the requested size. > > Debugging this a bit further, I think I'm just running out of stack > space. You are saying that this call can fail because of too small > a requested stack space, too? It might be nice to have some sort > of error message here instead of just an assert failure... > > How big is your stack limit on your mac? On mine it's 64 megabytes, > and when I added some printing: > > RTIO.PutText("Upthread.attr_getstacksize returned bytes="); > RTIO.PutInt(bytes); > RTIO.PutText(" defaultStackSize="); > RTIO.PutInt(defaultStackSize); > RTIO.PutChar('\n'); > > bytes := MAX(bytes, size * ADRSIZE(Word.T)); > WITH r = Upthread.attr_setstacksize(attr, bytes) DO > IF r # 0 THEN > RTIO.PutText("Upthread.attr_setstacksize failed, size="); > ELSE > RTIO.PutText("Upthread.attr_setstacksize succeeded, > size="); > END; > RTIO.PutInt(size); > RTIO.PutText(" bytes="); > RTIO.PutInt(bytes); > RTIO.PutChar('\n'); > <*ASSERT r=0*> > END; > RTIO.Flush(); > > I found the following: > > (running Wheeler) > > ... lots of times ... > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize succeeded, size=79632 bytes=524288 > Upthread.attr_getstacksize returned bytes=524288 > defaultStackSize=79632 > Upthread.attr_setstacksize failed, size=637056 bytes=2548224 > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/thread/PTHREAD/ThreadPThread.m3", line 692 > *** > > > Program exited with code 01. > > It's really a bug in mentor. Zeus.m3:499 calls IncDefaultStackSize > to request another 10 kilowords, Obliq.m3:32 calls IncDefaultStackSize > for another 64 kilowords , and WheelerCompressObliqView.m3 requests > 8*GetDefaultStackSize in a SizedClosure. A bunch of those threads > and I just run out of stack space. (I am assuming that pthreads > allocates stacks in the 'stack' segment of the process...) > > Attempting to fix the bug in mentor makes it run out of stack space, > looks like it's some recursive descent parser... Maybe this demo > just won't run on my computer. > >> Weird, I was running Bresenham just fine yesterday after the fix I >> checked in. Sounds like you may have some stale object files lying >> around. > > I was able to get it to run again. And deadlock again. And run > again... it's definitely something intermittent. I think it happens > right when it attempts to start the threads, not afterwards. > > And when you ctrl-C it, all you get is that it's stopped > in Trestle__AwaitDelete (I already sent this one). > >> >>> I really don't think it's my old system that's corrupting the new >>> images, >>> but I am *never* 100% certain of that. I found a very weird >>> behavior >>> with the build system, actually. I found that the not-yet-installed >>> compiler in /usr/local/cm3/pkg/cm3/PPC_DARWIN/ looks for cm3.cfg in >>> /usr/local/cm3/bin, but *only* if that is in the shell PATH. Is >>> that >>> a known/desired behavior? It causes the brand new compiler to >>> use the >>> old cm3.cfg, and it does so quietly without any warnings or messages >>> whatsoever. Changing your PATH makes it stop do that and instead >>> crash, >>> prompting me to put the cm3.cfg I want in the right place... >> >> I was not aware that you are mixing cm3.cfg versions. Why do you >> need both an old and a new one? In any case, this suggests that you >> want to rebuild the new system using the proper cm3.cfg and see if >> your problems go away. >> > > Here's what I'm doing... > > I install cm3-5.4.0 from the elegosoft site using that package's > cminstall. This installs a cm3.cfg. > > Then I follow your directions for bootstrapping from the CVS head. > At some point, those directions say to switch from using the original > compiler to the newly compiled compiler. > > Now, when you switch to the newly compiled compiler, the only cm3.cfg > in the system is the one from the bootstrappING compiler, that is, the > 5.4.0 release cm3.cfg. What happens is the following: > > 1. If my shell PATH includes the path to the old cm3, the new compiler > (silently) finds the old cm3.cfg and uses it. > > 2. If my shell PATH does not include the path to the old cm3, the new > compiler does not find the old cm3.cfg. > > This behavior will easily trip someone up who's trying to bootstrap > cm3, because I don't think any of the scripts (or bootstrapping > directions) do anything whatever to make sure that the new compiler > gets a new cm3.cfg. What I've taken to doing is taking cm3 out of > my PATH permanently so that I always have to type the full path. > That way I can't get a compiler-cfg mismatch, because the new compiler > will refuse to work until I have provided it with a new cm3.cfg. > I've been doing this for the last several bootstraps. > > > Mika From hosking at cs.purdue.edu Tue Aug 7 23:48:52 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 17:48:52 -0400 Subject: [M3devel] LONGINT Message-ID: Shortly I will be checking in compiler and run-time updates that enable the LONGINT type: 32 <= BITSIZE(INTEGER) <= BITSIZE(LONGINT) <= 64 Here are the changes to the language spec, in the form of context diffs to the updated reference manual, which is available at http:// www.cs.purdue.edu/~hosking/m3/reference/index.html. -------------- next part -------------- A non-text attachment was scrubbed... Name: Diffs Type: application/octet-stream Size: 15769 bytes Desc: not available URL: -------------- next part -------------- I have gone for the minimalist approach to adding LONGINT to the language. In brief, LONGINT is a distinct ordinal type from INTEGER. Conversions can be performed using ORD and VAL. For LONGINT 'n', ORD(n) converts n to an INTEGER. For INTEGER 'n', VAL (n, LONGINT) converts n to a LONGINT. Implicitly, this means all enumerations have an underlying INTEGER representation. LONGINT subranges work as expected. Open arrays are indexed by INTEGER values. Fixed arrays can have an index type whose base type is LONGINT. The rest of the changes to the language spec flow from these fundamentals. From hosking at cs.purdue.edu Wed Aug 8 00:05:03 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:05:03 -0400 Subject: [M3devel] LONGINT In-Reply-To: <469FD8A8.8070807@wichita.edu> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> Message-ID: Just responding to this w.r.to what I have implemented. On Jul 19, 2007, at 5:33 PM, Rodney M. Bates wrote: > > > Randy Coleburn wrote: >> Tony: >> I'd like to better understand the implications of your change as >> I do use LONGINT as an index in some applications. > > Do you have arrays that need 64-bit subscripts on a 32-bit machine? You can use a subrange of LONGINT for array indexes. The effective offset of an array element is still computed as an integer. Arrays are restricted in size, as they are currently. > Allow me the common assumption that both integers and addresses have > the native word size on most machines. In this case, most arrays that > need 64-bit subscripts would exceed the virtual address space of the > machine. Exceptions would require elements of size at most a byte, > and overall sizes in excess of half the virtual address space. Even > PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the > virtual space before 32-bit subscripts ran out. All this seems pretty > unlikely. Integers and addresses have the native word size. > I would favor keeping INTEGER as the type of open array subscripts > and not allowing LONGINT to be a fixed array subscript type. It > saves a whole lot of language complexity, and doesn't disallow much. I have done this. > If it really mattered, you could still use unsafe techniques for > such memory-hogging arrays. This might be a reason to extend unsafe > arithmetic on ADDRESS to accept LONGINT second operands. This is > actually consistent with the rest of the operator generalizations. >> > > -- > ------------------------------------------------------------- > 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 Wed Aug 8 00:07:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 18:07:08 -0400 Subject: [M3devel] LONGINT In-Reply-To: <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> References: <469F7BAD.1E75.00D7.1@scires.com> <469FD8A8.8070807@wichita.edu> <63B9DAA6-6A22-409C-B3BC-F7EF7C33B4C7@darko.org> Message-ID: I allow LONGINT indexed arrays, so long as the element offset can be computed as an integer. The size restriction on arrays remains. NUMBER always returns a CARDINAL. Thus, NUMBER(LONGINT) gives a range violation, just as NUMBER(INTEGER) currently does. However, NUMBER([10L .. 20L]) = NUMBER([10..20]) = 11. On Jul 19, 2007, at 6:02 PM, Darko wrote: > I think in 64 bit land you get a variety of combinations and > possibly the most common is a 32 bit address space with 64 bit > integers, since applications seldom need to operate in the larger > address space. But I would think it you wouldn't allocate an object > bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would > be more likely. > > The only situation where I can think of where this is an issue is > using a long integer index in an array of integer proportions, you > could handle this using arithmetic, also illustrates where you'd > need an implicit conversion: > > CONST > start = 2^63-500; > end = 2^63-200; > VAR > a: ARRAY[0..start-end+1] OF CHAR; > BEGIN > FOR i := start TO end DO a[INT(i-start)] := 'x' END; > > > Or you could rule that all arrays are of INTEGER size, but may have > a LONGINT index. Open arrays would always be integers. This would > probably be messy to implement and NUMBER would have a different > base to FIRST and LAST. That doesn't sound very good. > > > > On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote: > >> >> >> Randy Coleburn wrote: >>> Tony: >>> I'd like to better understand the implications of your change as >>> I do use LONGINT as an index in some applications. >> >> Do you have arrays that need 64-bit subscripts on a 32-bit machine? >> >> Allow me the common assumption that both integers and addresses have >> the native word size on most machines. In this case, most arrays >> that >> need 64-bit subscripts would exceed the virtual address space of the >> machine. Exceptions would require elements of size at most a byte, >> and overall sizes in excess of half the virtual address space. Even >> PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the >> virtual space before 32-bit subscripts ran out. All this seems >> pretty >> unlikely. >> >> I would favor keeping INTEGER as the type of open array subscripts >> and not allowing LONGINT to be a fixed array subscript type. It >> saves a whole lot of language complexity, and doesn't disallow much. >> >> If it really mattered, you could still use unsafe techniques for >> such memory-hogging arrays. This might be a reason to extend unsafe >> arithmetic on ADDRESS to accept LONGINT second operands. This is >> actually consistent with the rest of the operator generalizations. >>> >> >> -- >> ------------------------------------------------------------- >> 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 Wed Aug 8 05:59:12 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 7 Aug 2007 23:59:12 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems Message-ID: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Now I've checked in the LONGINT extensions, I am wondering if we shouldn't observe the following protocol for mapping INTEGER and LONGINT to C types. Currently, we have the following: 32-bit targets 64-bit targets INTEGER 32 bits 64 bits LONGINT 64 bits 64 bits C long int 32 bits 32 bits C long long 64 bits 64 bits I wonder if we shouldn't simply identify INTEGER as 32-bit and LONGINT as 64-bit on all targets. That way, INTEGER=long int and LONGINT=long long. Comments? From hosking at cs.purdue.edu Wed Aug 8 14:39:34 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:39:34 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> References: <20070808035016.A852410D440E@birch.elegosoft.com> <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Message-ID: <0B1FC476-C32B-4E57-8DC7-2856E85C1EF8@cs.purdue.edu> Make sure to start with clean build directories and clean before building with the bootstrapped compiler... On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > Amended bootstrap instructions: > > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3cc > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts ./do-cm3-std.sh realclean > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > >> CVSROOT: /usr/cvs >> Changes by: hosking at birch. 07/08/08 05:50:13 >> >> Modified files: >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html >> for.html index.html m3.html m3index.html >> numbers.html ordinal.html subtypes.html >> typeops.html word-intf.html >> cm3/m3-db/smalldb/src/: OSSupport.m3 >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 >> SocketPosix.m3 >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 >> cm3/m3-libs/m3core/src/thread/: m3makefile >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 >> Utypes.i3 >> m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 >> Utypes.i3 m3makefile >> cm3/m3-libs/m3core/src/word/: m3makefile >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c >> cm3/m3-sys/m3front/src/: m3makefile >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 >> Dec.m3 First.m3 Floatt.m3 >> Floor.m3 Inc.m3 Last.m3 >> Max.m3 New.m3 Number.m3 >> Ord.m3 Round.m3 Subarray.m3 >> Trunc.m3 Val.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 >> m3makefile >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 >> WordInsert.m3 WordModule.m3 >> WordNot.m3 WordOr.m3 >> WordRotate.m3 WordShift.m3 >> WordXor.m3 >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 >> CastExpr.m3 CheckExpr.m3 >> CompareExpr.m3 DivExpr.m3 >> EqualExpr.m3 Expr.m3 ExprParse.m3 >> InExpr.m3 IntegerExpr.i3 >> IntegerExpr.m3 ModExpr.m3 >> MultiplyExpr.m3 NegateExpr.m3 >> ReelExpr.i3 ReelExpr.m3 >> SetExpr.m3 SubscriptExpr.m3 >> SubtractExpr.m3 >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 >> Marker.m3 Scanner.m3 TipeDesc.i3 >> TipeDesc.m3 Token.i3 Token.m3 >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 >> ForStmt.m3 TryFinStmt.m3 >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 >> OpenArrayType.m3 SubrangeType.m3 >> Type.i3 Type.m3 >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 >> Module.m3 Variable.m3 >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 >> TWord.i3 TWord.m3 Target.i3 Target.m3 >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 >> M3Lexer.m3 M3Type.i3 M3Type.m3 >> cm3/m3-tools/m3browser/src/: Main.m3 >> Added files: >> cm3/doc/reference/: m3logo.gif >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 >> LongDivide.i3 LongDivide.m3 >> LongExtract.i3 >> LongExtract.m3 LongGE.i3 >> LongGE.m3 LongGT.i3 >> LongGT.m3 LongInsert.i3 >> LongInsert.m3 LongLE.i3 >> LongLE.m3 LongLT.i3 >> LongLT.m3 LongMinus.i3 >> LongMinus.m3 LongMod.i3 >> LongMod.m3 LongModule.i3 >> LongModule.m3 LongNot.i3 >> LongNot.m3 LongOr.i3 >> LongOr.m3 LongPlus.i3 >> LongPlus.m3 LongRotate.i3 >> LongRotate.m3 LongShift.i3 >> LongShift.m3 LongTimes.i3 >> LongTimes.m3 LongXor.i3 >> LongXor.m3 >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 >> >> Log message: >> Compiler and runtime extensions to support LONGINT type. >> >> Bootstrapping instructions: build and ship packages in the >> following order >> >> m3middle >> m3linker >> m3front >> m3quake >> cm3 >> >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. >> >> Use this new compiler to build and ship the new system: >> >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 >> cd cm3/scripts >> ./do-cm3-std.sh buildship >> >> If this is successful then move the new compiler to BINDIR: >> >> mv $CM3 INSTALL_DIR/bin/cm3 > From hosking at cs.purdue.edu Wed Aug 8 14:31:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 8 Aug 2007 08:31:36 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070808035016.A852410D440E@birch.elegosoft.com> References: <20070808035016.A852410D440E@birch.elegosoft.com> Message-ID: <9E7B2BE1-36D2-4D32-926D-CF70D7BBBC85@cs.purdue.edu> Amended bootstrap instructions: Compiler and runtime extensions to support LONGINT type. Bootstrapping instructions: build and ship packages in the following order m3cc m3middle m3linker m3front m3quake cm3 This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. Use this new compiler to build and ship the new system: export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 cd cm3/scripts ./do-cm3-std.sh buildship If this is successful then move the new compiler to BINDIR: mv $CM3 INSTALL_DIR/bin/cm3 On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > CVSROOT: /usr/cvs > Changes by: hosking at birch. 07/08/08 05:50:13 > > Modified files: > cm3/doc/reference/: arithmetic.html arrays.html conventions.html > for.html index.html m3.html m3index.html > numbers.html ordinal.html subtypes.html > typeops.html word-intf.html > cm3/m3-db/smalldb/src/: OSSupport.m3 > cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > SocketPosix.m3 > cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > cm3/m3-libs/m3core/src/thread/: m3makefile > cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > Utypes.i3 > m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > Utypes.i3 m3makefile > cm3/m3-libs/m3core/src/word/: m3makefile > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > cm3/m3-sys/m3front/src/: m3makefile > cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > Dec.m3 First.m3 Floatt.m3 > Floor.m3 Inc.m3 Last.m3 > Max.m3 New.m3 Number.m3 > Ord.m3 Round.m3 Subarray.m3 > Trunc.m3 Val.m3 > cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > m3makefile > cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > WordInsert.m3 WordModule.m3 > WordNot.m3 WordOr.m3 > WordRotate.m3 WordShift.m3 > WordXor.m3 > cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > CastExpr.m3 CheckExpr.m3 > CompareExpr.m3 DivExpr.m3 > EqualExpr.m3 Expr.m3 ExprParse.m3 > InExpr.m3 IntegerExpr.i3 > IntegerExpr.m3 ModExpr.m3 > MultiplyExpr.m3 NegateExpr.m3 > ReelExpr.i3 ReelExpr.m3 > SetExpr.m3 SubscriptExpr.m3 > SubtractExpr.m3 > cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > Marker.m3 Scanner.m3 TipeDesc.i3 > TipeDesc.m3 Token.i3 Token.m3 > cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > ForStmt.m3 TryFinStmt.m3 > cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > OpenArrayType.m3 SubrangeType.m3 > Type.i3 Type.m3 > cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > Module.m3 Variable.m3 > cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > TWord.i3 TWord.m3 Target.i3 Target.m3 > cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > M3Lexer.m3 M3Type.i3 M3Type.m3 > cm3/m3-tools/m3browser/src/: Main.m3 > Added files: > cm3/doc/reference/: m3logo.gif > cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > LongDivide.i3 LongDivide.m3 > LongExtract.i3 > LongExtract.m3 LongGE.i3 > LongGE.m3 LongGT.i3 > LongGT.m3 LongInsert.i3 > LongInsert.m3 LongLE.i3 > LongLE.m3 LongLT.i3 > LongLT.m3 LongMinus.i3 > LongMinus.m3 LongMod.i3 > LongMod.m3 LongModule.i3 > LongModule.m3 LongNot.i3 > LongNot.m3 LongOr.i3 > LongOr.m3 LongPlus.i3 > LongPlus.m3 LongRotate.i3 > LongRotate.m3 LongShift.i3 > LongShift.m3 LongTimes.i3 > LongTimes.m3 LongXor.i3 > LongXor.m3 > cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > Log message: > Compiler and runtime extensions to support LONGINT type. > > Bootstrapping instructions: build and ship packages in the > following order > > m3middle > m3linker > m3front > m3quake > cm3 > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > Use this new compiler to build and ship the new system: > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > cd cm3/scripts > ./do-cm3-std.sh buildship > > If this is successful then move the new compiler to BINDIR: > > mv $CM3 INSTALL_DIR/bin/cm3 From darko at darko.org Wed Aug 8 15:30:22 2007 From: darko at darko.org (Darko) Date: Wed, 8 Aug 2007 15:30:22 +0200 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> Message-ID: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> This might make sense as a platform option (ie where more than one platform config is available), where 32 bit integer performance is better, or you want to save memory. But INTEGERs are fairly fundamental. For instance, you might actually legitimately want to allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER wouldn't work on it. Will a integer subrange of a 64 bit INTEGER get handled by the back end as efficiently as a 'natively' defined 32 bit integer which is logically defined as a subrange? On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > Now I've checked in the LONGINT extensions, I am wondering if we > shouldn't observe the following protocol for mapping INTEGER and > LONGINT to C types. Currently, we have the following: > > > 32-bit targets 64-bit targets > > INTEGER 32 bits 64 bits > LONGINT 64 bits 64 bits > C long int 32 bits 32 bits > C long long 64 bits 64 bits > > I wonder if we shouldn't simply identify INTEGER as 32-bit and > LONGINT as 64-bit on all targets. That way, INTEGER=long int and > LONGINT=long long. > > Comments? > From rodney.bates at wichita.edu Wed Aug 8 17:20:48 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 10:20:48 -0500 Subject: [M3devel] No m3commit mailing list messages Message-ID: <46B9DF50.20608@wichita.edu> I have made three commits to m3gdb files inside the cm3 repository, on July 13, Aug 5 and Aug. 6. At least the first two seem to have gotten in to the repository, but there are no commit messages to this list. I had a delivery quota problem for a few days around the end of July, but I have checked the list archives via the web, and there are no messages there either. -- ------------------------------------------------------------- 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 ronny.forberger at elegosoft.com Wed Aug 8 21:30:32 2007 From: ronny.forberger at elegosoft.com (Ronny Forberger) Date: Wed, 08 Aug 2007 21:30:32 +0200 Subject: [M3devel] No m3commit mailing list messages In-Reply-To: <46B9DF50.20608@wichita.edu> References: <46B9DF50.20608@wichita.edu> Message-ID: <46BA19D8.1070108@elegosoft.com> You're right. You were not subscribed with rodney at elego.de which is the from address when you commit to our repository. I'm sorry, the person who created the subscriptions might have forgotten this address. Your messages should appear now though. Regards, Ronny Rodney M. Bates schrieb: > I have made three commits to m3gdb files inside the cm3 repository, > on July 13, Aug 5 and Aug. 6. At least the first two seem to have > gotten in to the repository, but there are no commit messages to > this list. I had a delivery quota problem for a few days around > the end of July, but I have checked the list archives via the web, > and there are no messages there either. > -- Ronny Forberger Systemadministration & IT-Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Geb?ude 12, Raum 227 D-13355 Berlin Tel. +49 30 23 45 86 96 ronny.forberger at elegosoft.com Fax +49 30 23 45 86 95 http://www.elegosoft.com Gesch?ftsf?hrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 From rodney.bates at wichita.edu Thu Aug 9 01:10:30 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:10:30 -0500 Subject: [M3devel] Different forms of the language definition Message-ID: <46BA4D66.6040507@wichita.edu> I checked in a .tex, a one-page .html, and a .ps version of the Modula-3 language definition, with the intent to get them consistent with each other and the multi-page html version. Does anyone have any ideas about the best way to derive the different forms from a single source, or how it was originally done? I personally don't find an on-line form very usable, and printing multiple html pages is both tedious to do and rather bad-looking to use. Even a paper print of the one-page html form doesn't look great. My favorite is a .ps or .pdf. But the .ps I had and checked in appears to be been converted from a one-page html form and looks like a print from a web browser. I can easily produce a nice .ps from the .tex with Latex. I am sure some will prefer other forms than I do. -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 9 01:20:22 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 08 Aug 2007 18:20:22 -0500 Subject: [M3devel] Threads summary for m3gdb Message-ID: <46BA4FB6.5090807@wichita.edu> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- 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 rcoleburn at scires.com Thu Aug 9 01:27:55 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Wed, 08 Aug 2007 19:27:55 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <46BA192B.1E75.00D7.1@scires.com> Rodney: I believe that on Windows (Win32) the implementation uses native OS threads. At least that is how it worked for cm v4.1. Regards, Randy Randy C. Coleburn Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> I have been doing some work on m3gdb lately and am mulling over trying to improve the very rudimentary thread support. With the new thread implementation, it is a good time. I would like confirmation (or correction) of the following impressions I have gotten about thread handling in implementations of Modula-3. Here's what I think I understand: The old system uses threads entirely implemented in libm3core, using setjmp/longjmp to get execution moved around where it is needed. The new system, called for by -DPTHREAD uses the pthreads library instead. There is no use of any kind of kernel threads. The old thread system is tied to the older GC, which requires that system-dependent wrappers be used for many OS system calls. The new thread system is tied to the new GC, which doesn't need the wrappers, but has the compiler inserting calls to the GC in a few places. Is this all correct? -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Aug 9 10:50:12 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:50:12 +0200 (CEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: <41532.194.138.127.36.1186649412.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:10, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? It's been some years since I've done it, but you can use LaTeX as source and produce high-quality PS and PDF output (dvips, dvipdf) as well as HTML (there were several tools at the time). Alternatively you could use DocBook/SGML tools (as for example the FreeBSD project does (at least, did some years ago ;-)). Personally I'd think LaTeX is fine and will be easier. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 9 10:53:53 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 9 Aug 2007 10:53:53 +0200 (CEST) Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <45691.194.138.127.36.1186649633.squirrel@mail.elegosoft.com> On Thu, August 9, 2007 01:20, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. This is true for the POSIX platforms; on Windows, always native system threads have been used. > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. Pthreads interfaces may be mapped to kernel threads, depending on the operating system and its configuration. > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. I don't think this is correct. GC changes are independent of the threads changes (though both were done by Antony Hosking). He may correct me of course. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? See above, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From lemming at henning-thielemann.de Thu Aug 9 15:02:49 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 09 Aug 2007 15:02:49 +0200 (MEST) Subject: [M3devel] Different forms of the language definition In-Reply-To: <46BA4D66.6040507@wichita.edu> References: <46BA4D66.6040507@wichita.edu> Message-ID: On Wed, 8 Aug 2007, Rodney M. Bates wrote: > I checked in a .tex, a one-page .html, and a .ps version of the > Modula-3 language definition, with the intent to get them consistent > with each other and the multi-page html version. > > Does anyone have any ideas about the best way to derive the different > forms from a single source, or how it was originally done? > > I personally don't find an on-line form very usable, and printing multiple > html pages is both tedious to do and rather bad-looking to use. Even a > paper print of the one-page html form doesn't look great. My favorite is > a .ps or .pdf. But the .ps I had and checked in appears to be been > converted from a one-page html form and looks like a print from a web > browser. I can easily produce a nice .ps from the .tex with Latex. The PostScript version I downloaded from somewhere years ago looked like generated with TeX (at least not from HTML). I think this is the way to go. From hosking at cs.purdue.edu Fri Aug 10 05:42:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:42:51 -0400 Subject: [M3devel] INTEGER and LONGINT on 64-bit systems In-Reply-To: <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> References: <68DD3FAE-84DB-4449-A22A-11C19180FD0F@cs.purdue.edu> <794A25BF-4DF6-4E7F-A830-C88118189B87@darko.org> Message-ID: <7C34CE31-81ED-4488-B0A2-D34D13CC0E0F@cs.purdue.edu> On Aug 8, 2007, at 9:30 AM, Darko wrote: > This might make sense as a platform option (ie where more than one > platform config is available), where 32 bit integer performance is > better, or you want to save memory. But INTEGERs are fairly > fundamental. For instance, you might actually legitimately want to > allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER > wouldn't work on it. On second thoughts.... Given how integer is intimately tied up with Word.T and many assume BITSIZE(INTEGER)=BITSIZE(ADDRESS) I think we probably want INTEGER left as it currently stands. > Will a integer subrange of a 64 bit INTEGER get handled by the back > end as efficiently as a 'natively' defined 32 bit integer which is > logically defined as a subrange? Currently subranges with LONGINT base have values represented as LONGINT. A subrange of LONGINT can be used as an array index for an array, so long as NUMBER(array) is restricted, just as it is currently. > > > > On 08/08/2007, at 5:59 AM, Tony Hosking wrote: > >> Now I've checked in the LONGINT extensions, I am wondering if we >> shouldn't observe the following protocol for mapping INTEGER and >> LONGINT to C types. Currently, we have the following: >> >> >> 32-bit targets 64-bit targets >> >> INTEGER 32 bits 64 bits >> LONGINT 64 bits 64 bits >> C long int 32 bits 32 bits >> C long long 64 bits 64 bits >> >> I wonder if we shouldn't simply identify INTEGER as 32-bit and >> LONGINT as 64-bit on all targets. That way, INTEGER=long int and >> LONGINT=long long. >> >> Comments? >> From hosking at cs.purdue.edu Fri Aug 10 05:58:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:21 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA4FB6.5090807@wichita.edu> References: <46BA4FB6.5090807@wichita.edu> Message-ID: <62EDD983-A3B8-4A11-B1F5-2636FB977A70@cs.purdue.edu> On Aug 8, 2007, at 7:20 PM, Rodney M. Bates wrote: > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > Here's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. Yes, though this needs migration to using getcontext/setcontext/ makecontext instead so as to work properly on systems that implement secure setjmp/longjmp. > The new system, called for by -DPTHREAD uses the pthreads library > instead. Yes. gdb handles pthreads on most systems. > There is no use of any kind of kernel threads. pthreads are usually scheduled as a thin veneer over kernel threads. For example, there is a 1-1 map between pthreads and Mach threads on Darwin (similarly for Solaris and Linux). > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. Not true. The old thread system works fine with the new GC. > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. Not true. The new GC works fine with the old threads system. > Is this all correct? Hope this helps. > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 05:58:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 9 Aug 2007 23:58:51 -0400 Subject: [M3devel] Threads summary for m3gdb In-Reply-To: <46BA192B.1E75.00D7.1@scires.com> References: <46BA4FB6.5090807@wichita.edu> <46BA192B.1E75.00D7.1@scires.com> Message-ID: <9BAA4292-AD96-43DD-A3C8-0DA4F89D9C4B@cs.purdue.edu> Yes, on Win32, M3 threads are win32 threads. On Aug 8, 2007, at 7:27 PM, Randy Coleburn wrote: > Rodney: > > I believe that on Windows (Win32) the implementation uses native OS > threads. At least that is how it worked for cm v4.1. > > Regards, > Randy > > Randy C. Coleburn > Senior Systems Engineer, Communications, Networks, & Electronics > Division (CNE) > Corporate & Atlanta Information Systems Security Manager (ISSM) > Scientific Research Corporation > 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 > voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) > 989-9497 > > Quality Policy: "SRC CNE Division is committed to delivering > continually improving research & engineering excellence that meets > or exceeds customer requirements." > > >>> "Rodney M. Bates" 8/8/2007 7:20 PM >>> > I have been doing some work on m3gdb lately and am mulling over > trying to improve the very rudimentary thread support. With > the new thread implementation, it is a good time. I would like > confirmation (or correction) of the following impressions I have > gotten about thread handling in implementations of Modula-3. > > H! ere's what I think I understand: > > The old system uses threads entirely implemented in libm3core, > using setjmp/longjmp to get execution moved around where it is > needed. > > The new system, called for by -DPTHREAD uses the pthreads library > instead. > > There is no use of any kind of kernel threads. > > The old thread system is tied to the older GC, which requires that > system-dependent wrappers be used for many OS system calls. > > The new thread system is tied to the new GC, which doesn't need > the wrappers, but has the compiler inserting calls to the GC in > a few places. > > Is this all correct? > > -- > ------------------------------------------------------------- > 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 Fri Aug 10 10:11:24 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 10 Aug 2007 10:11:24 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: Message-ID: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> On Fri, August 10, 2007 01:57, Alex Bochannek wrote: > A couple of quick comments about the CM3 build process on Solaris/SPARC. > > 1) /usr/local/cm3 is hardcoded in a few places in sysinfo.sh. I > installed the minimal binaries in /opt/cm3 and needed to change > sysinfo.sh. I would be surprised if that would be all; supporting other installation locations by the simple build scripts has really not been a target until now. Improvements are always welcome though, so if you have patches that make this abstraction they're sure to get included. > 2) cm3cg is linked against libiconv.so.2. This is not a standard Solaris > library, at least not on Solaris 10. I will install the GNU libiconv and > see if that works. cm3cg is the standard GNU compiler backend, so it may need some (ever increasing) infrastructure (i.e. other GNU libraries). We should either declare this as an explicit dependency (i.e. installation prerequisite) or include it in our installation archives. Probably it hasn't been missing for anybody else using M3 so far, because gcc was always installed before. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jayk123 at hotmail.com Sat Aug 11 15:55:14 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 13:55:14 +0000 Subject: [M3devel] compiling the C code as C++? Message-ID: I was going through diffs I had around. One set is mostly putting #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif around all the C code, and a little something for the K&R code. The point was to compile all the C code as C++. I assume I had it working but I'll have to get back up to speed to verify that. Thoughts? - Jay _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 16:26:56 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 14:26:56 +0000 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? Message-ID: I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really? Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some. Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history". All you need is the following: signed and unsigned integer types that are exactly 8 bits in size signed and unsigned integer types that are exactly 16 bits in size signed and unsigned integer types that are exactly 32 bits in size signed and unsigned integer types that are exactly 64 bits in size signed and unsigned integer types that are exactly the size of a pointer 10 integer types total, named something like: INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit: int => INT => INT_PTR unsigned => UINT => UINT_PTR DWORD => DWORD_PTR convert to the upper case types if not there, and append "_PTR" The existing types size_t and ptrdiff_t did change size. If someone really needed 32 bit types there, you'd have to change your code. Windows has more than that for historical and stylistics reasons -- upper case types, lowercase types, types that "favor" being unsigned int or unsigned long. Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary. C 9x adds in "fast" and "small" types types that are the smallest type that is at least a certain size, I think types that are the fastest type that are at least a certain size, I think the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out beyond necessity. Yeah, obviously, they seem like maybe you might want them, but it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient to use on all forseeable processors, since tons of code uses them, and people should not will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are mostly stupid these days and they very often should be widened, but folks can do that "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used. Why has this been so hard in Modula-3? Is it that "Word" is widely used and has been pointer sized? Or that INTEGER has been widely used and sometimes assumed to be pointer sized? Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but weren't done right and there is some legacy we are stuck with?? Do "subrange" types make it all confusing? Or merely the assignment rules among the non subrange integer types? I have not paid particularly close attention; it just has always surprised me that it was difficult to work out what to do. I guess it is all moot now, the issues have been worked out and the feature is there. Good. I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly abstracted C names "short", "int", "long" are a useful abstraction. I think you really want the 10 base types I first listed. btw, even the types that are same size as a pointer are overused in C/C++. You don't need them for as much pointer arithmetic as people use. You can use "char*" for that. They are useful for array indices though, the result of wcslen, sizeof(), etc. File sizes should always be UINT64.. - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 17:15:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 11:15:06 -0400 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> I think you have reasonably illustrated just why C/C++ is such a mess. In M3 we have "BITS n FOR ..." to get appropriately sized things, equivalent to C/C++ char, short, long, long long. The split between INTEGER and LONGINT is unfortunate perhaps, but represents an explicit signal to programmers that INTEGER and LONGINT have different underlying representations, which is in the spirit of Modula-3's existing type system. Perhaps we should be explicit in the C type mappings for M3 by writing: char = BITS 8 FOR ... short = BITS 16 FOR ... int = BITS 32 FOR ... long_long = BITS 64 FOR ... On Aug 11, 2007, at 10:26 AM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! From darko at darko.org Sat Aug 11 17:17:15 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:17:15 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: References: Message-ID: <3AAAC6BE-6742-4B5C-882F-980D1DA39D00@darko.org> The point of M3 is not be different than some other language, the point is for it to be safe, and, as a side effect, easy to use. Making a language safe is hard becuase you have to consider every possible usage and outcome becuase the language guarantees that it will not produce an "unchecked" error for the safe subset of the language, that is, it will do something random no matter how use use the language. So we have to consider all changes very carefully. On 11/08/2007, at 4:26 PM, j k wrote: > I know, like, the point of Modula-3 is to not be like C or C++ and > to revisit everything in them, but..really? > > Windows programming in C and C++ has had this solved reasonable for > MANY YEARS. > Other folks solved it similarly even longer ago, though I would > claim Windows's > approach has been successfully applied to more code -- that is, all > of Windows, and then some. > > Windows C/C++ is flawed here, but not in a too terrible way. > In particular, Windows C/C++ has too many names for the same types, > with various > flimsy rationale, mostly "style" and "history". > > All you need is the following: > > signed and unsigned integer types that are exactly 8 bits in size > signed and unsigned integer types that are exactly 16 bits in size > signed and unsigned integer types that are exactly 32 bits in size > signed and unsigned integer types that are exactly 64 bits in size > signed and unsigned integer types that are exactly the size of a > pointer > > 10 integer types total, named something like: > INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t > or UINT_PTR, ptrdiff_t or INT_PTR > > The types "int" and "long" and unsigned thereof NEVER changed size. > Where people were using them for pointer sized things, you would > do a simple transform to port to 64 bit: > int => INT => INT_PTR > unsigned => UINT => UINT_PTR > DWORD => DWORD_PTR > > convert to the upper case types if not there, and append "_PTR" > > The existing types size_t and ptrdiff_t did change size. > If someone really needed 32 bit types there, you'd have to change > your code. > > Windows has more than that for historical and stylistics reasons > -- upper case types, > lowercase types, types that "favor" being unsigned int or > unsigned long. > > Some of it is C's fault -- the "short" and "long" stuff seems all > unnecessary. > > C 9x adds in "fast" and "small" types > types that are the smallest type that is at least a certain > size, I think > types that are the fastest type that are at least a certain > size, I think > the idea here being that if 64 bit integers are "faster" than > 32 bit integers, then "fast32" might be 64 bits > > In reality, I think the 10 types are confusing enough, but > necessary, C9x multiplies out > beyond necessity. Yeah, obviously, they seem like maybe you > might want them, but > it's just too many times imho. Imho 8, 16, and 32 bit integers > must remain efficient > to use on all forseeable processors, since tons of code uses > them, and people should not > will not be pushed to widen everything across the board. Yeah, > 64K and 4GB limits are > mostly stupid these days and they very often should be widened, > but folks can do that > "slowly" on their own, managing compatibilit themselves -- like > where binary file i/o is used. > > Why has this been so hard in Modula-3? > > Is it that "Word" is widely used and has been pointer sized? > Or that INTEGER has been widely used and sometimes assumed to be > pointer sized? > > Is it that Sparc64 (?) and 64 bit Alpha have existed for a long > time but > weren't done right and there is some legacy we are stuck with?? > > Do "subrange" types make it all confusing? > > Or merely the assignment rules among the non subrange integer types? > > I have not paid particularly close attention; it just has always > surprised me > that it was difficult to work out what to do. > > I guess it is all moot now, the issues have been worked out and > the feature is there. Good. > > I am skeptical that the name "LONGINT" is good. I am skeptical > that the slightly > abstracted C names "short", "int", "long" are a useful abstraction. > I think you really want the 10 base types I first listed. > > btw, even the types that are same size as a pointer are overused in > C/C++. > You don't need them for as much pointer arithmetic as people use. > You can use "char*" for that. > They are useful for array indices though, the result of wcslen, > sizeof(), etc. > > File sizes should always be UINT64.. > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sat Aug 11 17:26:44 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 17:26:44 +0200 Subject: [M3devel] rant -- Why has 64 bit integer support been so hard? In-Reply-To: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> References: <58B3E221-AEE0-4E81-B3F5-6DD1323D874E@cs.purdue.edu> Message-ID: <74C18A3E-B31F-4D95-AF21-81A770F86B7E@darko.org> INTEGER in M3 is much more abstract than C, you can use it largely without thinking about what size it is, or at least you should. Portability and simplicity are other benefits you get with M3 compared to C++. On 11/08/2007, at 5:15 PM, Tony Hosking wrote: > I think you have reasonably illustrated just why C/C++ is such a > mess. In M3 we have "BITS n FOR ..." to get appropriately sized > things, equivalent to C/C++ char, short, long, long long. The > split between INTEGER and LONGINT is unfortunate perhaps, but > represents an explicit signal to programmers that INTEGER and > LONGINT have different underlying representations, which is in the > spirit of Modula-3's existing type system. Perhaps we should be > explicit in the C type mappings for M3 by writing: > > char = BITS 8 FOR ... > short = BITS 16 FOR ... > int = BITS 32 FOR ... > long_long = BITS 64 FOR ... > > On Aug 11, 2007, at 10:26 AM, j k wrote: > >> I know, like, the point of Modula-3 is to not be like C or C++ and >> to revisit everything in them, but..really? >> >> Windows programming in C and C++ has had this solved reasonable >> for MANY YEARS. >> Other folks solved it similarly even longer ago, though I would >> claim Windows's >> approach has been successfully applied to more code -- that is, >> all of Windows, and then some. >> >> Windows C/C++ is flawed here, but not in a too terrible way. >> In particular, Windows C/C++ has too many names for the same >> types, with various >> flimsy rationale, mostly "style" and "history". >> >> All you need is the following: >> >> signed and unsigned integer types that are exactly 8 bits in size >> signed and unsigned integer types that are exactly 16 bits in size >> signed and unsigned integer types that are exactly 32 bits in size >> signed and unsigned integer types that are exactly 64 bits in size >> signed and unsigned integer types that are exactly the size of a >> pointer >> >> 10 integer types total, named something like: >> INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, >> size_t or UINT_PTR, ptrdiff_t or INT_PTR >> >> The types "int" and "long" and unsigned thereof NEVER changed size. >> Where people were using them for pointer sized things, you would >> do a simple transform to port to 64 bit: >> int => INT => INT_PTR >> unsigned => UINT => UINT_PTR >> DWORD => DWORD_PTR >> >> convert to the upper case types if not there, and append "_PTR" >> >> The existing types size_t and ptrdiff_t did change size. >> If someone really needed 32 bit types there, you'd have to >> change your code. >> >> Windows has more than that for historical and stylistics reasons >> -- upper case types, >> lowercase types, types that "favor" being unsigned int or >> unsigned long. >> >> Some of it is C's fault -- the "short" and "long" stuff seems all >> unnecessary. >> >> C 9x adds in "fast" and "small" types >> types that are the smallest type that is at least a certain >> size, I think >> types that are the fastest type that are at least a certain >> size, I think >> the idea here being that if 64 bit integers are "faster" than >> 32 bit integers, then "fast32" might be 64 bits >> >> In reality, I think the 10 types are confusing enough, but >> necessary, C9x multiplies out >> beyond necessity. Yeah, obviously, they seem like maybe you >> might want them, but >> it's just too many times imho. Imho 8, 16, and 32 bit integers >> must remain efficient >> to use on all forseeable processors, since tons of code uses >> them, and people should not >> will not be pushed to widen everything across the board. Yeah, >> 64K and 4GB limits are >> mostly stupid these days and they very often should be widened, >> but folks can do that >> "slowly" on their own, managing compatibilit themselves -- like >> where binary file i/o is used. >> >> Why has this been so hard in Modula-3? >> >> Is it that "Word" is widely used and has been pointer sized? >> Or that INTEGER has been widely used and sometimes assumed to be >> pointer sized? >> >> Is it that Sparc64 (?) and 64 bit Alpha have existed for a long >> time but >> weren't done right and there is some legacy we are stuck with?? >> >> Do "subrange" types make it all confusing? >> >> Or merely the assignment rules among the non subrange integer >> types? >> >> I have not paid particularly close attention; it just has always >> surprised me >> that it was difficult to work out what to do. >> >> I guess it is all moot now, the issues have been worked out and >> the feature is there. Good. >> >> I am skeptical that the name "LONGINT" is good. I am skeptical >> that the slightly >> abstracted C names "short", "int", "long" are a useful abstraction. >> I think you really want the 10 base types I first listed. >> >> btw, even the types that are same size as a pointer are overused >> in C/C++. >> You don't need them for as much pointer arithmetic as people use. >> You can use "char*" for that. >> They are useful for array indices though, the result of wcslen, >> sizeof(), etc. >> >> File sizes should always be UINT64.. >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From jayk123 at hotmail.com Sat Aug 11 19:06:57 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:06:57 +0000 Subject: [M3devel] [M3commit] CVS Update: cm3 Message-ID: I can build the compiler, but, youch, can't build m3core\long.m3: "..\src\word\Long.m3", line 11: Unknown type of size other than dword in movOp The x86 back end needs work..I'll see if I can't just provide this stuff in C and avoid understanding the backend much.. - Jay> From: hosking at cs.purdue.edu> Date: Wed, 8 Aug 2007 08:39:34 -0400> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com; m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > Make sure to start with clean build directories and clean before > building with the bootstrapped compiler...> > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote:> > > Amended bootstrap instructions:> >> > Compiler and runtime extensions to support LONGINT type.> > > > Bootstrapping instructions: build and ship packages in the > > following order> > > > m3cc> > m3middle> > m3linker> > m3front> > m3quake> > cm3> > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> > > > Use this new compiler to build and ship the new system:> > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> > cd cm3/scripts> > ./do-cm3-std.sh realclean> > > ./do-cm3-std.sh buildship> > > > If this is successful then move the new compiler to BINDIR:> > > > mv $CM3 INSTALL_DIR/bin/cm3> >> > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote:> >> >> CVSROOT: /usr/cvs> >> Changes by: hosking at birch. 07/08/08 05:50:13> >>> >> Modified files:> >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html> >> for.html index.html m3.html m3index.html> >> numbers.html ordinal.html subtypes.html> >> typeops.html word-intf.html> >> cm3/m3-db/smalldb/src/: OSSupport.m3> >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3> >> SocketPosix.m3> >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3> >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3> >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c> >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3> >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3> >> cm3/m3-libs/m3core/src/thread/: m3makefile> >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3> >> Utypes.i3> >> m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3> >> Utypes.i3 m3makefile> >> cm3/m3-libs/m3core/src/word/: m3makefile> >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c> >> cm3/m3-sys/m3front/src/: m3makefile> >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3> >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3> >> Dec.m3 First.m3 Floatt.m3> >> Floor.m3 Inc.m3 Last.m3> >> Max.m3 New.m3 Number.m3> >> Ord.m3 Round.m3 Subarray.m3> >> Trunc.m3 Val.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3> >> m3makefile> >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3> >> WordInsert.m3 WordModule.m3> >> WordNot.m3 WordOr.m3> >> WordRotate.m3 WordShift.m3> >> WordXor.m3> >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3> >> CastExpr.m3 CheckExpr.m3> >> CompareExpr.m3 DivExpr.m3> >> EqualExpr.m3 Expr.m3 ExprParse.m3> >> InExpr.m3 IntegerExpr.i3> >> IntegerExpr.m3 ModExpr.m3> >> MultiplyExpr.m3 NegateExpr.m3> >> ReelExpr.i3 ReelExpr.m3> >> SetExpr.m3 SubscriptExpr.m3> >> SubtractExpr.m3> >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3> >> Marker.m3 Scanner.m3 TipeDesc.i3> >> TipeDesc.m3 Token.i3 Token.m3> >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3> >> ForStmt.m3 TryFinStmt.m3> >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3> >> OpenArrayType.m3 SubrangeType.m3> >> Type.i3 Type.m3> >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3> >> Module.m3 Variable.m3> >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3> >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3> >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3> >> TWord.i3 TWord.m3 Target.i3 Target.m3> >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3> >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3> >> M3Lexer.m3 M3Type.i3 M3Type.m3> >> cm3/m3-tools/m3browser/src/: Main.m3> >> Added files:> >> cm3/doc/reference/: m3logo.gif> >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3> >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3> >> LongDivide.i3 LongDivide.m3> >> LongExtract.i3> >> LongExtract.m3 LongGE.i3> >> LongGE.m3 LongGT.i3> >> LongGT.m3 LongInsert.i3> >> LongInsert.m3 LongLE.i3> >> LongLE.m3 LongLT.i3> >> LongLT.m3 LongMinus.i3> >> LongMinus.m3 LongMod.i3> >> LongMod.m3 LongModule.i3> >> LongModule.m3 LongNot.i3> >> LongNot.m3 LongOr.i3> >> LongOr.m3 LongPlus.i3> >> LongPlus.m3 LongRotate.i3> >> LongRotate.m3 LongShift.i3> >> LongShift.m3 LongTimes.i3> >> LongTimes.m3 LongXor.i3> >> LongXor.m3> >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3> >>> >> Log message:> >> Compiler and runtime extensions to support LONGINT type.> >> > >> Bootstrapping instructions: build and ship packages in the > >> following order> >> > >> m3middle> >> m3linker> >> m3front> >> m3quake> >> cm3> >> > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3.> >> > >> Use this new compiler to build and ship the new system:> >> > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3> >> cd cm3/scripts> >> ./do-cm3-std.sh buildship> >> > >> If this is successful then move the new compiler to BINDIR:> >> > >> mv $CM3 INSTALL_DIR/bin/cm3> >> _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 19:14:21 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:14:21 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: References: Message-ID: <078AEEB2-F545-43ED-B01D-2783D318C4F9@cs.purdue.edu> Did you rebuild the backend? I have built this on Darwin x86 and Linux x86 without problems. On Aug 11, 2007, at 1:06 PM, j k wrote: > I can build the compiler, but, youch, can't build m3core\long.m3: > > "..\src\word\Long.m3", line 11: Unknown type of size other than > dword in movOp > > The x86 back end needs work..I'll see if I can't just provide this > stuff in C and avoid understanding the backend much.. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Wed, 8 Aug 2007 08:39:34 -0400 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com; m3commit at elegosoft.com > > Subject: Re: [M3commit] CVS Update: cm3 > > > > Make sure to start with clean build directories and clean before > > building with the bootstrapped compiler... > > > > On Aug 8, 2007, at 8:31 AM, Tony Hosking wrote: > > > > > Amended bootstrap instructions: > > > > > > Compiler and runtime extensions to support LONGINT type. > > > > > > Bootstrapping instructions: build and ship packages in the > > > following order > > > > > > m3cc > > > m3middle > > > m3linker > > > m3front > > > m3quake > > > cm3 > > > > > > This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > > > > > Use this new compiler to build and ship the new system: > > > > > > export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > > cd cm3/scripts > > > > ./do-cm3-std.sh realclean > > > > > ./do-cm3-std.sh buildship > > > > > > If this is successful then move the new compiler to BINDIR: > > > > > > mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > On Aug 8, 2007, at 5:50 AM, Antony Hosking wrote: > > > > > >> CVSROOT: /usr/cvs > > >> Changes by: hosking at birch. 07/08/08 05:50:13 > > >> > > >> Modified files: > > >> cm3/doc/reference/: arithmetic.html arrays.html conventions.html > > >> for.html index.html m3.html m3index.html > > >> numbers.html ordinal.html subtypes.html > > >> typeops.html word-intf.html > > >> cm3/m3-db/smalldb/src/: OSSupport.m3 > > >> cm3/m3-libs/libm3/src/os/POSIX/: FSPosix.m3 FilePosix.m3 > > >> SocketPosix.m3 > > >> cm3/m3-libs/libm3/src/pickle/ver2/: ConvertPacking.m3 > > >> cm3/m3-libs/m3core/src/C/32BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/C/64BITS/: BasicCtypes.i3 > > >> cm3/m3-libs/m3core/src/Csupport/Common/: hand.c > > >> cm3/m3-libs/m3core/src/runtime/POSIX/: RTOS.m3 > > >> cm3/m3-libs/m3core/src/runtime/common/: RTTipe.i3 RTTipe.m3 > > >> cm3/m3-libs/m3core/src/thread/: m3makefile > > >> cm3/m3-libs/m3core/src/unix/darwin-generic/: Umman.i3 Unix.i3 > > >> Utypes.i3 > > >> m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-2/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-3/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/freebsd-4/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/unix/netbsd2-i386/: Umman.i3 Unix.i3 > > >> Utypes.i3 m3makefile > > >> cm3/m3-libs/m3core/src/word/: m3makefile > > >> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c > > >> cm3/m3-sys/m3front/src/: m3makefile > > >> cm3/m3-sys/m3front/src/builtinInfo/: InfoThisLine.m3 > > >> cm3/m3-sys/m3front/src/builtinOps/: Abs.m3 BitSize.m3 Ceiling.m3 > > >> Dec.m3 First.m3 Floatt.m3 > > >> Floor.m3 Inc.m3 Last.m3 > > >> Max.m3 New.m3 Number.m3 > > >> Ord.m3 Round.m3 Subarray.m3 > > >> Trunc.m3 Val.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: BuiltinTypes.m3 Int.m3 > > >> m3makefile > > >> cm3/m3-sys/m3front/src/builtinWord/: WordAnd.m3 WordExtract.m3 > > >> WordInsert.m3 WordModule.m3 > > >> WordNot.m3 WordOr.m3 > > >> WordRotate.m3 WordShift.m3 > > >> WordXor.m3 > > >> cm3/m3-sys/m3front/src/exprs/: AddExpr.m3 ArrayExpr.m3 > > >> CastExpr.m3 CheckExpr.m3 > > >> CompareExpr.m3 DivExpr.m3 > > >> EqualExpr.m3 Expr.m3 ExprParse.m3 > > >> InExpr.m3 IntegerExpr.i3 > > >> IntegerExpr.m3 ModExpr.m3 > > >> MultiplyExpr.m3 NegateExpr.m3 > > >> ReelExpr.i3 ReelExpr.m3 > > >> SetExpr.m3 SubscriptExpr.m3 > > >> SubtractExpr.m3 > > >> cm3/m3-sys/m3front/src/misc/: CG.i3 CG.m3 Coverage.m3 M3Front.m3 > > >> Marker.m3 Scanner.m3 TipeDesc.i3 > > >> TipeDesc.m3 Token.i3 Token.m3 > > >> cm3/m3-sys/m3front/src/stmts/: AssignStmt.m3 DebugStmt.m3 > > >> ForStmt.m3 TryFinStmt.m3 > > >> cm3/m3-sys/m3front/src/types/: ArrayType.m3 EnumType.m3 > > >> OpenArrayType.m3 SubrangeType.m3 > > >> Type.i3 Type.m3 > > >> cm3/m3-sys/m3front/src/values/: Exceptionz.m3 Formal.m3 > > >> Module.m3 Variable.m3 > > >> cm3/m3-sys/m3middle/src/: M3Buf.m3 M3CG_BinRd.m3 M3CG_BinWr.m3 > > >> M3CG_Check.m3 M3CG_Rd.m3 M3CG_Wr.m3 > > >> TFloat.i3 TFloat.m3 TInt.i3 TInt.m3 > > >> TWord.i3 TWord.m3 Target.i3 Target.m3 > > >> cm3/m3-sys/m3scanner/src/: M3Scanner.i3 M3Scanner.m3 > > >> cm3/m3-sys/m3tools/src/: M3AST.i3 M3Builtin.m3 M3Const.m3 > > >> M3Lexer.m3 M3Type.i3 M3Type.m3 > > >> cm3/m3-tools/m3browser/src/: Main.m3 > > >> Added files: > > >> cm3/doc/reference/: m3logo.gif > > >> cm3/m3-libs/m3core/src/word/: Long.i3 Long.m3 > > >> cm3/m3-sys/m3front/src/builtinLong/: LongAnd.i3 LongAnd.m3 > > >> LongDivide.i3 LongDivide.m3 > > >> LongExtract.i3 > > >> LongExtract.m3 LongGE.i3 > > >> LongGE.m3 LongGT.i3 > > >> LongGT.m3 LongInsert.i3 > > >> LongInsert.m3 LongLE.i3 > > >> LongLE.m3 LongLT.i3 > > >> LongLT.m3 LongMinus.i3 > > >> LongMinus.m3 LongMod.i3 > > >> LongMod.m3 LongModule.i3 > > >> LongModule.m3 LongNot.i3 > > >> LongNot.m3 LongOr.i3 > > >> LongOr.m3 LongPlus.i3 > > >> LongPlus.m3 LongRotate.i3 > > >> LongRotate.m3 LongShift.i3 > > >> LongShift.m3 LongTimes.i3 > > >> LongTimes.m3 LongXor.i3 > > >> LongXor.m3 > > >> cm3/m3-sys/m3front/src/builtinTypes/: LInt.i3 LInt.m3 > > >> > > >> Log message: > > >> Compiler and runtime extensions to support LONGINT type. > > >> > > >> Bootstrapping instructions: build and ship packages in the > > >> following order > > >> > > >> m3middle > > >> m3linker > > >> m3front > > >> m3quake > > >> cm3 > > >> > > >> This places a new compiler in INSTALL_DIR/pkg/cm3/TARGET/cm3. > > >> > > >> Use this new compiler to build and ship the new system: > > >> > > >> export CM3=INSTALL_DIR/pkg/cm3/TARGET/cm3 > > >> cd cm3/scripts > > >> ./do-cm3-std.sh buildship > > >> > > >> If this is successful then move the new compiler to BINDIR: > > >> > > >> mv $CM3 INSTALL_DIR/bin/cm3 > > > > > > > > Recharge--play some free games. Win cool prizes too! Play It! From hosking at cs.purdue.edu Sat Aug 11 19:19:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 13:19:56 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details References: <200708111715.l7BHFAJn017822@hermes50.mail.cornell.edu> Message-ID: Jay, your e-mails are bouncing. Begin forwarded message: > From: Mail Delivery Subsystem > Date: August 11, 2007 1:15:10 PM EDT > To: hosking at cs.purdue.edu > Subject: Returned mail: see transcript for details > > The original message was received at Sat, 11 Aug 2007 13:15:10 > -0400 (EDT) > from daemon at localhost > > ----- The following addresses had permanent fatal errors ----- > jaykrell at verizon.net > > ----- Transcript of session follows ----- > ... while talking to relay.verizon.net.: >>>> DATA > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > 550 5.1.1 jaykrell at verizon.net... User unknown > <<< 554 5.5.0 No recipients have been specified. > Reporting-MTA: dns; hermes50.mail.cornell.edu > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > Final-Recipient: RFC822; jaykrell at verizon.net > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; relay.verizon.net > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > From: Tony Hosking > Date: August 11, 2007 1:14:21 PM EDT > To: > Cc: Modula-3 developers , > > Subject: Re: [M3commit] CVS Update: cm3 > > > Did you rebuild the backend? > > I have built this on Darwin x86 and Linux x86 without problems. > > On Aug 11, 2007, at 1:06 PM, j k wrote: > >> I can build the compiler, but, youch, can't build m3core\long.m3: >> >> "..\src\word\Long.m3", line 11: Unknown type of size other than >> dword in movOp >> >> The x86 back end needs work..I'll see if I can't just provide this >> stuff in C and avoid understanding the backend much.. >> >> - Jay >> From jayk123 at hotmail.com Sat Aug 11 19:55:06 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 17:55:06 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:53:00 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:53:00 +0000 Subject: [M3devel] Fwd: Returned mail: see transcript for details Message-ID: Ok, other than calling it "the x86 backend", I think I'm right. I wasn't sure if it was for all x86 platforms or just Windows.How about the "non gcc" backend? I think only Windows uses it and no other platform.I can get much further still having fixed BuildStandalone functionality in m3-sys\cminstall\src\config\NT386. I broke it a few months ago. I got as far as m3ui and something with RTHeapDep, I think the problem there is the interface got deleted between the last binary distribution and now. I'll dig a bit more.After fixing BuildStandalone, tried again with the inline Long.m3 and got the same errors so I put back my C implementation -- I am NOT sure it is right, either in calling convention or in implementing the shift/rotate/extract/insert stuff correctly.Now cm3 -ship works on m3core.dll as well but that's a different point. - JayFrom: jayk123 at hotmail.comTo: hosking at cs.purdue.edu; m3devel at elegosoft.comDate: Sat, 11 Aug 2007 17:55:06 +0000Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details Yeah sorry I have to fix that forwarding, been broken for months but almost have it fixed. jayk123 at hotmail.com works. Hm. Geez I don't know. I guess I should stop submitting for now. Let me figure more stuff out. I built cm3.exe and am running it. I had more errors before fixing the Windows clearenv.cmd, I submitted a fix for it -- it was clearing %cm3%. I have to track down where the gcc vs. no gcc decision is made. Maybe it is only x86 Windows that uses this code, not all x86 platforms? I can get further with my changes but then I crash and I probably won't make much more progress today. - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 13:19:56 -0400> To: m3devel at elegosoft.com> Subject: [M3devel] Fwd: Returned mail: see transcript for details> > Jay, your e-mails are bouncing.> > Begin forwarded message:> > > From: Mail Delivery Subsystem > > Date: August 11, 2007 1:15:10 PM EDT> > To: hosking at cs.purdue.edu> > Subject: Returned mail: see transcript for details> >> > The original message was received at Sat, 11 Aug 2007 13:15:10 > > -0400 (EDT)> > from daemon at localhost> >> > ----- The following addresses had permanent fatal errors -----> > jaykrell at verizon.net> >> > ----- Transcript of session follows -----> > ... while talking to relay.verizon.net.:> >>>> DATA> > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net> > 550 5.1.1 jaykrell at verizon.net... User unknown> > <<< 554 5.5.0 No recipients have been specified.> > Reporting-MTA: dns; hermes50.mail.cornell.edu> > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > Final-Recipient: RFC822; jaykrell at verizon.net> > Action: failed> > Status: 5.1.1> > Remote-MTA: DNS; relay.verizon.net> > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT)> >> > From: Tony Hosking > > Date: August 11, 2007 1:14:21 PM EDT> > To: > > Cc: Modula-3 developers , > > > > Subject: Re: [M3commit] CVS Update: cm3> >> >> > Did you rebuild the backend?> >> > I have built this on Darwin x86 and Linux x86 without problems.> >> > On Aug 11, 2007, at 1:06 PM, j k wrote:> >> >> I can build the compiler, but, youch, can't build m3core\long.m3:> >>> >> "..\src\word\Long.m3", line 11: Unknown type of size other than > >> dword in movOp> >>> >> The x86 back end needs work..I'll see if I can't just provide this > >> stuff in C and avoid understanding the backend much..> >>> >> - Jay> >>> New home for Mom, no cleanup required. All starts here. _________________________________________________________________ Messenger Caf? ? open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sat Aug 11 20:54:55 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 11 Aug 2007 18:54:55 +0000 Subject: [M3devel] missing commits Message-ID: fyi, I'm not seeing my commits, probably my fault with my screwy-for-months-now mail configuration. I do intend to fix it soon... - Jay _________________________________________________________________ Recharge--play some free games. Win cool prizes too! http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Aug 11 21:03:32 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 15:03:32 -0400 Subject: [M3devel] Fwd: Returned mail: see transcript for details In-Reply-To: References: Message-ID: Ah, yes the Windows (non-gcc) x86 backed will certainly need fixing to handle 64-bit integers. I had forgotten that Windows does not use the gcc-based backend. The principal differences can probably be figured out by looking at how Long.m3 gets compiled. Take a look at the changes to M3CG_Ops.i3 to get a sense for what changes were made to the interface between the middle and back ends. On Aug 11, 2007, at 2:53 PM, j k wrote: > Ok, other than calling it "the x86 backend", I think I'm right. I > wasn't sure if it was for all x86 platforms or just Windows. > > How about the "non gcc" backend? I think only Windows uses it and > no other platform. > > I can get much further still having fixed BuildStandalone > functionality in m3-sys\cminstall\src\config\NT386. I broke it a > few months ago. I got as far as m3ui and something with RTHeapDep, > I think the problem there is the interface got deleted between the > last binary distribution and now. I'll dig a bit more. > > After fixing BuildStandalone, tried again with the inline Long.m3 > and got the same errors so I put back my C implementation -- I am > NOT sure it is right, either in calling convention or in > implementing the shift/rotate/extract/insert stuff correctly. > > Now cm3 -ship works on m3core.dll as well but that's a different > point. > > - Jay > > From: jayk123 at hotmail.com > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sat, 11 Aug 2007 17:55:06 +0000 > Subject: Re: [M3devel] Fwd: Returned mail: see transcript for details > > Yeah sorry I have to fix that forwarding, been broken for months > but almost have it fixed. > jayk123 at hotmail.com works. > > Hm. Geez I don't know. I guess I should stop submitting for now. > Let me figure more stuff out. > > I built cm3.exe and am running it. I had more errors before fixing > the Windows clearenv.cmd, I submitted a fix for it -- it was > clearing %cm3%. > > I have to track down where the gcc vs. no gcc decision is made. > Maybe it is only x86 Windows that uses this code, not all x86 > platforms? > > I can get further with my changes but then I crash and I probably > won't make much more progress today. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 13:19:56 -0400 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Fwd: Returned mail: see transcript for details > > > > Jay, your e-mails are bouncing. > > > > Begin forwarded message: > > > > > From: Mail Delivery Subsystem > > > Date: August 11, 2007 1:15:10 PM EDT > > > To: hosking at cs.purdue.edu > > > Subject: Returned mail: see transcript for details > > > > > > The original message was received at Sat, 11 Aug 2007 13:15:10 > > > -0400 (EDT) > > > from daemon at localhost > > > > > > ----- The following addresses had permanent fatal errors ----- > > > jaykrell at verizon.net > > > > > > ----- Transcript of session follows ----- > > > ... while talking to relay.verizon.net.: > > >>>> DATA > > > <<< 550 4.2.1 mailbox temporarily disabled: jaykrell at verizon.net > > > 550 5.1.1 jaykrell at verizon.net... User unknown > > > <<< 554 5.5.0 No recipients have been specified. > > > Reporting-MTA: dns; hermes50.mail.cornell.edu > > > Arrival-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > Final-Recipient: RFC822; jaykrell at verizon.net > > > Action: failed > > > Status: 5.1.1 > > > Remote-MTA: DNS; relay.verizon.net > > > Last-Attempt-Date: Sat, 11 Aug 2007 13:15:10 -0400 (EDT) > > > > > > From: Tony Hosking > > > Date: August 11, 2007 1:14:21 PM EDT > > > To: > > > Cc: Modula-3 developers , > > > > > > Subject: Re: [M3commit] CVS Update: cm3 > > > > > > > > > Did you rebuild the backend? > > > > > > I have built this on Darwin x86 and Linux x86 without problems. > > > > > > On Aug 11, 2007, at 1:06 PM, j k wrote: > > > > > >> I can build the compiler, but, youch, can't build m3core\long.m3: > > >> > > >> "..\src\word\Long.m3", line 11: Unknown type of size other than > > >> dword in movOp > > >> > > >> The x86 back end needs work..I'll see if I can't just provide > this > > >> stuff in C and avoid understanding the backend much.. > > >> > > >> - Jay > > >> > > > > > New home for Mom, no cleanup required. All starts here. > Messenger Caf? ? open for fun 24/7. Hot games, cool activities > served daily. Visit now. From darko at darko.org Sat Aug 11 22:15:22 2007 From: darko at darko.org (Darko) Date: Sat, 11 Aug 2007 22:15:22 +0200 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> The last commit I got was beginning of April. I think there might be a wider problem. On 11/08/2007, at 8:54 PM, j k wrote: > fyi, I'm not seeing my commits, probably my fault with my screwy- > for-months-now mail configuration. I do intend to fix it soon... > > - Jay > > Recharge--play some free games. Win cool prizes too! Play It! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 01:01:40 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 19:01:40 -0400 Subject: [M3devel] missing commits In-Reply-To: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> References: <43BFE0BC-37C2-44E4-85A2-4351D0544610@darko.org> Message-ID: <7B496A29-42B3-499E-9CF9-5AF651C72075@cs.purdue.edu> I know there was a problem with the mailing list and I ended up re- subscribing using my CVS username from the elegosoft web-site. It seems that commits via CVS accounts pipe to the mailing list, but you need to be subscribed with that id. On Aug 11, 2007, at 4:15 PM, Darko wrote: > The last commit I got was beginning of April. I think there might > be a wider problem. > > > On 11/08/2007, at 8:54 PM, j k wrote: > >> fyi, I'm not seeing my commits, probably my fault with my screwy- >> for-months-now mail configuration. I do intend to fix it soon... >> >> - Jay >> >> Recharge--play some free games. Win cool prizes too! Play It! > From rodney.bates at wichita.edu Sun Aug 12 02:44:18 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Sat, 11 Aug 2007 19:44:18 -0500 Subject: [M3devel] Latex M3 language definition Message-ID: <46BE57E2.90307@wichita.edu> I propose to fix up m3-defn-complete.tex as much as possible before adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can have an up to date-PM3-definition. The .tex I found does not have any face tags for the code samples in the running text (as does the .html), nor does it have anything denoting the hyperlinks in it. I guess they will have to be inserted manually. This would quite a bit of stuff to try to merge with the CM3 changes, if they were to get done first. Other than that, the .tex looks like the actual content is very close to identical to the .html one-page form. I did a careful parallel reading, (as close as mere mortals could have much hope of doing). So the .tex is not exactly the predecessor that the .html was derived from. I have done some net searching trying to find another .tex, but to no avail, so far. It does look like latex2html will do what is needed, particularly allowing tex tags that will turn into hyperlinks in html and get ignored by latex for a printed version. It also appears to have something for optionally generating multi-page html as well. I think there is a successor to it, but haven't checked that out yet. -- ------------------------------------------------------------- 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 Sun Aug 12 04:05:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 11 Aug 2007 22:05:28 -0400 Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: I'm halfwa done on some of that, so hang on a mo'. On Aug 11, 2007, at 8:44 PM, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. > > Other than that, the .tex looks like the actual content is very close > to identical to the .html one-page form. I did a careful parallel > reading, (as close as mere mortals could have much hope of doing). > So the .tex is not exactly the predecessor that the .html was derived > from. I have done some net searching trying to find another .tex, > but to no avail, so far. > > It does look like latex2html will do what is needed, particularly > allowing tex tags that will turn into hyperlinks in html and get > ignored by latex for a printed version. It also appears to have > something for optionally generating multi-page html as well. I think > there is a successor to it, but haven't checked that out yet. > > -- > ------------------------------------------------------------- > 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 lemming at henning-thielemann.de Sun Aug 12 06:52:29 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 12 Aug 2007 06:52:29 +0200 (MEST) Subject: [M3devel] Latex M3 language definition In-Reply-To: <46BE57E2.90307@wichita.edu> References: <46BE57E2.90307@wichita.edu> Message-ID: On Sat, 11 Aug 2007, Rodney M. Bates wrote: > I propose to fix up m3-defn-complete.tex as much as possible before > adding the WIDECHAR, WIDETEXT, and LONGINT stuff. That way, we can > have an up to date-PM3-definition. The .tex I found does not have > any face tags for the code samples in the running text (as does the > .html), nor does it have anything denoting the hyperlinks in it. > I guess they will have to be inserted manually. This would quite a > bit of stuff to try to merge with the CM3 changes, if they were to get > done first. I also remember that the Module-3 definition states that only one exception per EXCEPTION keyword can be defined, which seems to be relaxed in cm3 and pm3. From derick_eddington at yahoo.com Sun Aug 12 06:49:23 2007 From: derick_eddington at yahoo.com (Derick Eddington) Date: Sat, 11 Aug 2007 21:49:23 -0700 (PDT) Subject: [M3devel] unsubcribe Message-ID: <982895.80961.qm@web58713.mail.re1.yahoo.com> ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From jayk123 at hotmail.com Sun Aug 12 07:24:06 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 05:24:06 +0000 Subject: [M3devel] missing commits Message-ID: I am getting Tony's .tex commits, but didn't see mine.I say this half to cover my butt -- I made some commits.If I'm not seeing them, others maybe aren't either.I added a C version of Long.m3 for Win32.Not sure it is right, in a few ways. How it uses the stack. If it shifts and all by the right amounts? (n or 64 - n?) It definitely lets the build progress further. Surely it isn't ideal -- the C code actually generates calls out to the C runtime even, under the covers, so what was meant to be inlined is a two deep call tree! (The compiler generates the calls.)I fixed cminstall/src/config/NT386 so BuildStandalone works.I fixed scripts/win/clearenv.cmd so the user can set CM3 as per Tony's bootstrap instructions.Maybe others, don't recall.Nothing large.I figure I'll remove a bunch of extra semicolons in some C code.Any thoughts on the #ifdef __cplusplus extern "C" in C code? - Jay> From: hosking at cs.purdue.edu> Date: Sat, 11 Aug 2007 19:01:40 -0400> To: darko at darko.org> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > I know there was a problem with the mailing list and I ended up re- > subscribing using my CVS username from the elegosoft web-site. It > seems that commits via CVS accounts pipe to the mailing list, but you > need to be subscribed with that id.> > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > > The last commit I got was beginning of April. I think there might > > be a wider problem.> >> >> > On 11/08/2007, at 8:54 PM, j k wrote:> >> >> fyi, I'm not seeing my commits, probably my fault with my screwy- > >> for-months-now mail configuration. I do intend to fix it soon...> >>> >> - Jay> >>> >> Recharge--play some free games. Win cool prizes too! Play It!> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 10:16:22 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 04:16:22 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <389194AD-D205-47E0-808A-E6BBC15A2CA3@cs.purdue.edu> Why do you need a C version of Long.m3 for Win32? These operations are built into the front-end, making use of backend functionality. On Aug 12, 2007, at 1:24 AM, j k wrote: > I am getting Tony's .tex commits, but didn't see mine. > I say this half to cover my butt -- I made some commits. > If I'm not seeing them, others maybe aren't either. > > I added a C version of Long.m3 for Win32. > Not sure it is right, in a few ways. > How it uses the stack. > If it shifts and all by the right amounts? (n or 64 - n?) > It definitely lets the build progress further. > Surely it isn't ideal -- the C code actually generates > calls out to the C runtime even, under the covers, so what > was meant to be inlined is a two deep call tree! > (The compiler generates the calls.) > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > I fixed scripts/win/clearenv.cmd so the user > can set CM3 as per Tony's bootstrap instructions. > > Maybe others, don't recall. > Nothing large. > > I figure I'll remove a bunch of extra semicolons in some C code. > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > To: darko at darko.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > I know there was a problem with the mailing list and I ended up re- > > subscribing using my CVS username from the elegosoft web-site. It > > seems that commits via CVS accounts pipe to the mailing list, but > you > > need to be subscribed with that id. > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > The last commit I got was beginning of April. I think there might > > > be a wider problem. > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > >> fyi, I'm not seeing my commits, probably my fault with my screwy- > > >> for-months-now mail configuration. I do intend to fix it soon... > > >> > > >> - Jay > > >> > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Sun Aug 12 14:39:34 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 12 Aug 2007 14:39:34 +0200 Subject: [M3devel] Error building cvshead m3gdb od x86_64 Linux Message-ID: <1186922374.9120.24.camel@faramir.m3w.org> gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/i386-linux-nat.c In file included from ../../gdb/gdb/i386-linux-nat.c:65: ../../gdb/gdb/gregset.h:63: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?gdb_fpxregset_t? ../../gdb/gdb/gregset.h:65: error: expected ?)? before ?*? token ../../gdb/gdb/gregset.h:66: error: expected ?)? before ?*? token -- Dragi?a Duri? From jayk123 at hotmail.com Sun Aug 12 21:20:07 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:20:07 +0000 Subject: [M3devel] missing commits Message-ID: Because it doesn't work currently. This was easier but I agree not ideal. - Jay> From: hosking at cs.purdue.edu> Date: Sun, 12 Aug 2007 04:16:22 -0400> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] missing commits> > Why do you need a C version of Long.m3 for Win32? These operations > are built into the front-end, making use of backend functionality.> > On Aug 12, 2007, at 1:24 AM, j k wrote:> > > I am getting Tony's .tex commits, but didn't see mine.> > I say this half to cover my butt -- I made some commits.> > If I'm not seeing them, others maybe aren't either.> >> > I added a C version of Long.m3 for Win32.> > Not sure it is right, in a few ways.> > How it uses the stack.> > If it shifts and all by the right amounts? (n or 64 - n?)> > It definitely lets the build progress further.> > Surely it isn't ideal -- the C code actually generates> > calls out to the C runtime even, under the covers, so what> > was meant to be inlined is a two deep call tree!> > (The compiler generates the calls.)> >> > I fixed cminstall/src/config/NT386 so BuildStandalone works.> >> > I fixed scripts/win/clearenv.cmd so the user> > can set CM3 as per Tony's bootstrap instructions.> >> > Maybe others, don't recall.> > Nothing large.> >> > I figure I'll remove a bunch of extra semicolons in some C code.> >> > Any thoughts on the #ifdef __cplusplus extern "C" in C code?> >> > - Jay> >> > > From: hosking at cs.purdue.edu> > > Date: Sat, 11 Aug 2007 19:01:40 -0400> > > To: darko at darko.org> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] missing commits> > >> > > I know there was a problem with the mailing list and I ended up re-> > > subscribing using my CVS username from the elegosoft web-site. It> > > seems that commits via CVS accounts pipe to the mailing list, but > > you> > > need to be subscribed with that id.> > >> > > On Aug 11, 2007, at 4:15 PM, Darko wrote:> > >> > > > The last commit I got was beginning of April. I think there might> > > > be a wider problem.> > > >> > > >> > > > On 11/08/2007, at 8:54 PM, j k wrote:> > > >> > > >> fyi, I'm not seeing my commits, probably my fault with my screwy-> > > >> for-months-now mail configuration. I do intend to fix it soon...> > > >>> > > >> - Jay> > > >>> > > >> Recharge--play some free games. Win cool prizes too! Play It!> > > >> > >> >> > See what you?re getting into?before you go there See it!> _________________________________________________________________ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Aug 12 21:27:05 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:27:05 +0000 Subject: [M3devel] new Win32 build from current source Message-ID: Can folks try this? Make it available on the web page?There hasn't been a win32 release for longer than other platforms.I can build "core" and "std" if folks want.These files are directly output from scripts\win\make-dist.cmd. It has the support for "core" and "std", commented out. If folks prefer, tar.gz, .zip, and self extracting .zip are possible; .bz2 is smallest. Perhaps a version number should be in the .tar path structure? The install instructions are like (no cminstall, replaced by using vcvars32.bat which lets one CM3 install move among different tools, debatable which is better) cd /d c:\ optionally rmdir /q/s cm3 tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 run the usual vcvars32.bat or whatever (or use the start menu link that Visual C++ setup creates) set PATH=c:\cm3\bin;%PATH% set LIB=c:\cm3\lib;%lib% optionally, a good test: cd \scripts\win .\do-pkg-std realclean .\do-pkg-std buildship I have not tested the longint stuff and it likely doesn't work yet. The files are in ~jkrell on m3.elegosoft.com: C:\>ssh jkrell at m3.elegosoft.com find . ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 Remember you will need http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE-A3F9-4C13-9C99-220B62A191EE or http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 or I could build it with an older toolset if folks want. Thanks, - Jay _________________________________________________________________ Find a local pizza place, movie theater, and more?.then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Aug 12 21:32:02 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:32:02 -0400 Subject: [M3devel] missing commits In-Reply-To: References: Message-ID: <14E40138-3008-42B2-AD21-C6AA96DFFA12@cs.purdue.edu> Not only not ideal, but deferring the pain. We need to be able to compile 64-bit operations on 32-bit machines and that means updating the backend. Long.m3 is a good test-case for all the ops that you need for LONGINT support. On Aug 12, 2007, at 3:20 PM, j k wrote: > Because it doesn't work currently. This was easier but I agree not > ideal. > > - Jay > > > From: hosking at cs.purdue.edu > > Date: Sun, 12 Aug 2007 04:16:22 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] missing commits > > > > Why do you need a C version of Long.m3 for Win32? These operations > > are built into the front-end, making use of backend functionality. > > > > On Aug 12, 2007, at 1:24 AM, j k wrote: > > > > > I am getting Tony's .tex commits, but didn't see mine. > > > I say this half to cover my butt -- I made some commits. > > > If I'm not seeing them, others maybe aren't either. > > > > > > I added a C version of Long.m3 for Win32. > > > Not sure it is right, in a few ways. > > > How it uses the stack. > > > If it shifts and all by the right amounts? (n or 64 - n?) > > > It definitely lets the build progress further. > > > Surely it isn't ideal -- the C code actually generates > > > calls out to the C runtime even, under the covers, so what > > > was meant to be inlined is a two deep call tree! > > > (The compiler generates the calls.) > > > > > > I fixed cminstall/src/config/NT386 so BuildStandalone works. > > > > > > I fixed scripts/win/clearenv.cmd so the user > > > can set CM3 as per Tony's bootstrap instructions. > > > > > > Maybe others, don't recall. > > > Nothing large. > > > > > > I figure I'll remove a bunch of extra semicolons in some C code. > > > > > > Any thoughts on the #ifdef __cplusplus extern "C" in C code? > > > > > > - Jay > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Sat, 11 Aug 2007 19:01:40 -0400 > > > > To: darko at darko.org > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] missing commits > > > > > > > > I know there was a problem with the mailing list and I ended > up re- > > > > subscribing using my CVS username from the elegosoft web- > site. It > > > > seems that commits via CVS accounts pipe to the mailing list, > but > > > you > > > > need to be subscribed with that id. > > > > > > > > On Aug 11, 2007, at 4:15 PM, Darko wrote: > > > > > > > > > The last commit I got was beginning of April. I think there > might > > > > > be a wider problem. > > > > > > > > > > > > > > > On 11/08/2007, at 8:54 PM, j k wrote: > > > > > > > > > >> fyi, I'm not seeing my commits, probably my fault with my > screwy- > > > > >> for-months-now mail configuration. I do intend to fix it > soon... > > > > >> > > > > >> - Jay > > > > >> > > > > >> Recharge--play some free games. Win cool prizes too! Play It! > > > > > > > > > > > > > > > See what you?re getting into?before you go there See it! > > > > > New home for Mom, no cleanup required. All starts here. From hosking at cs.purdue.edu Sun Aug 12 21:34:30 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Aug 2007 15:34:30 -0400 Subject: [M3devel] new Win32 build from current source In-Reply-To: References: Message-ID: <83F32D11-E8ED-4CD8-B400-F3DDE7795D56@cs.purdue.edu> LONGINT will need work on the native x86 backend. Should not be too hard, given how little needed to change for the gcc-based backend to handle LONGINT. [PS I have a couple of fixes to LONGINT that I am working on in the front-end compiler. Issues with LONGINT subranges and their representation. I am hoping this fixes the bug I discovered in LONGINT on PPC_DARWIN w.r.to off_t in file stat structs.] On Aug 12, 2007, at 3:27 PM, j k wrote: > Can folks try this? Make it available on the web page? > There hasn't been a win32 release for longer than other platforms. > I can build "core" and "std" if folks want. > These files are directly output from scripts\win\make-dist.cmd. > It has the support for "core" and "std", commented out. > If folks prefer, tar.gz, .zip, and self extracting .zip are > possible; .bz2 is smallest. > Perhaps a version number should be in the .tar path structure? > > The install instructions are like (no cminstall, replaced by using > vcvars32.bat which lets one CM3 install move among different tools, > debatable which is better) > > cd /d c:\ > optionally rmdir /q/s cm3 > tar xvjf cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > run the usual vcvars32.bat or whatever (or use the start menu link > that Visual C++ setup creates) > set PATH=c:\cm3\bin;%PATH% > set LIB=c:\cm3\lib;%lib% > > optionally, a good test: > cd \scripts\win > .\do-pkg-std realclean > .\do-pkg-std buildship > > I have not tested the longint stuff and it likely doesn't work yet. > > The files are in ~jkrell on m3.elegosoft.com: > C:\>ssh jkrell at m3.elegosoft.com find . > > ./cm3-min-WIN32-NT386-d5.5.0-symbols.tar.bz2 > ./cm3-min-WIN32-NT386-d5.5.0.tar.bz2 > > Remember you will need > http://www.microsoft.com/downloads/details.aspx?familyid=32BC1BEE- > A3F9-4C13-9C99-220B62A191EE > or http://www.microsoft.com/downloads/details.aspx? > FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647 > > or I could build it with an older toolset if folks want. > > Thanks, > - Jay > > Find a local pizza place, movie theater, and more?.then map the > best route! Find it! From jayk123 at hotmail.com Sun Aug 12 21:39:31 2007 From: jayk123 at hotmail.com (j k) Date: Sun, 12 Aug 2007 19:39:31 +0000 Subject: [M3devel] Some random notes on building/running Modula-3 on Windows (XP). Message-ID: Some of this is redundant -- i.e. has long been working. Some of it is specific to my configuration and habits. You are expected to recognize that. :) I am running Windows XP and currently using Visual C++ 8.0, though many versions of NT and VC should work. Some work has been put into ensuring multiple versions of VC work. Checkout the latest source. Really the latest. (at least of August 12 11am Pacific time). Download and extract the "latest" binary distribution, it is old but ok: cm3-min-WIN32-NT386-5.2.6.tar.bz2 Or maybe it was .gz, I always change them to save space. For me it is at C:\net\modula3\cm3-min-WIN32-NT386-5.2.6.tar.bz2 I install to the default c:\cm3. Prior to running cminstall, mkdir c:\cm3\t. Whenever cminstall asks for a path to a directory, just say c:\cm3\t. (It insists on an existing path, but with my configuration file, which is generic and checked in, none of them are used.) None of these paths matters if you do things this way. After running cminstall, you may rmdir the empty c:\cm3\t. Replace c:\cm3\bin\cm3.cfg with the latest source's cm3\m3-sys\cminstall\src\config\NT386. No edits are necessary. Or, if doing this repeatedly, I have it like so: cm3-min-WIN32-NT386-5.2.6.tar.bz2 is extracted to \net\modula3\cm3-min-WIN32-NT386-5.2.6\t and modified: delete bin\cm3.cfg delete bin\cm3.cfg--default and then to restore just: xcopy /fiveryh \net\modula3\cm3-min-WIN32-NT386-5.2.6\t \cm3 You need /h for hidden because tar will hide files like .M3EXPORTS that start with a dot. t for temp Setup your Visual C++ environment (%PATH%, %LIB%, %INCLUD%) by running the usual vcvars32.bat. For me this is running \env\cm3.vc80.bat (also have \env\cm3.vc20.bat, 40, 41, 42, 50, 60, 70, 71) set LIB=c:\cm3\lib;%LIB% set PATH=c:\cm3\bin;%PATH% Given the source tree at \dev2\cm3.2 I use \dev2 since Unix "takes" \dev. cm3.2 is because cm3 is an older tree I need to get the diffs out of and delete. These instructions are based on Tony's and very similar. Mainly that Windows does not use gcc. cd \dev2\cm3.2\scripts\win @rem make sure %CM3% is clear, in case of running through this stuff multiple times. set CM3= .\do-pkg realclean import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 .\do-pkg buildship import-libs m3middle m3linker m3front m3quake m3objfile m3back m3staloneback m3objfile cm3 set CM3=C:\dev2\cm3.2\m3-sys\cm3\NT386\cm3.exe .\do-cm3-std realclean .\do-cm3-std buildship .\install-cm3-compiler upgrade Alternatively: extract/install/configure latest distribution as above checkout latest source cd scripts\win .\make-dist This gives you: cm3-min-WIN32-NT386-d5.3.2.tar.bz2 cm3-min-WIN32-NT386-d5.3.2-symbols.tar.bz2 buried in temp. I have not tested the new LONGINT functionality and there's a good chance it doesn't work yet. Various GUI apps start up ok. formsedit starts up and show gui. juno starts and shows gui, but crashes easily: *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\winvbt\WinContext.m3", line 165 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x5aaf830 0xf41c9a PushPixmap + 0x43c in ..\src\winvbt\WinContext.m3 0x5aaf8f8 0xf4fc2c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3 0x5aafd54 0xf4db55 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3 0x5aafdbc 0xf4843e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3 0x5aafe04 0xf46d3d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3 0x5aafe30 0x7e418734 0x5aafe98 0x7e418816 0x5aafef8 0x7e4189cd 0x5aaff08 0x7e4196c7 0x5aaff50 0xf4baf4 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3 ......... ......... ... more frames ... vorun brings up gui visobliq brings up gui not sure how to exit, had to kill it shownew brings up gui showheap brings up gui showthread brings up gui - Jay _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stsp at elego.de Mon Aug 13 21:44:47 2007 From: stsp at elego.de (Stefan Sperling) Date: Mon, 13 Aug 2007 21:44:47 +0200 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813143915.71BE510D4363@birch.elegosoft.com> References: <20070813143915.71BE510D4363@birch.elegosoft.com> Message-ID: <20070813194447.GE1351@ted.stsp.lan> On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > CVSROOT: /usr/cvs > Changes by: rodney at birch. 07/08/13 16:39:15 > > Modified files: > cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c > > Log message: > No change to the contents of these files. This is an attempt to get > the time stampof ada-lex.c to be later than that of ada-lex.l. This > will mean m3gdb will build without requiring flex to be installed. What about hacking a 'touch ada-lex.c' into the Makefile somewhere instead? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From rodney.bates at wichita.edu Mon Aug 13 23:41:32 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 16:41:32 -0500 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20070813194447.GE1351@ted.stsp.lan> References: <20070813143915.71BE510D4363@birch.elegosoft.com> <20070813194447.GE1351@ted.stsp.lan> Message-ID: <46C0D00C.5030903@wichita.edu> This works when I do a complete fresh cvs checkout on a different machine and build, with flex disabled. The checked-out files on the second machine show the times I edited my originals on the first machine, before committing. But when, on yet a 3rd machine, I do a cvs update, both files show identical times, the time that the update happened. So something more is needed. Is there a way to get cvs to give updated files the time they have in the repository, instead of when updated? If anybody ever actually did change ada-lex.l, a touch ada-lex.c in the makefile would be wrong. After what I did, people who do an update now may go from building fine (since they got the files initially from a checkout, which gives the right time ordering), to failing. Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 04:39:15PM +0000, Rodney M. Bates wrote: > >>CVSROOT: /usr/cvs >>Changes by: rodney at birch. 07/08/13 16:39:15 >> >>Modified files: >> cm3/m3-sys/m3gdb/gdb/gdb/: ada-lex.c >> >>Log message: >> No change to the contents of these files. This is an attempt to get >> the time stampof ada-lex.c to be later than that of ada-lex.l. This >> will mean m3gdb will build without requiring flex to be installed. > > > What about hacking a 'touch ada-lex.c' into the Makefile somewhere > instead? > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:11:44 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:11:44 -0500 Subject: [M3devel] A note on bootstrapping cm3 Message-ID: <46C0D720.90202@wichita.edu> If you have not rebootstrapped cm3 in a while, you may have, in your cm3.cfg, something similar to: GCWRAPFLAGS = "-Wl,--wrap,adjtime,--wrap,getdirentries,--wrap,readv,--wrap,utimes,--wrap,wait3" To build with recent cm3 compilers, this has to change to: GCWRAPFLAGS = "" The immediate symptom of this problem is link failures during building, with messages similar to undefined reference to `__wrap_utimes' -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Tue Aug 14 00:14:41 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Mon, 13 Aug 2007 17:14:41 -0500 Subject: [M3devel] A note on building m3gdb Message-ID: <46C0D7D1.3000009@wichita.edu> If you don't have a working flex installed, you may get a failure trying to build m3gdb, complaining about not being able to regenerate ada-lex.c. If this happens, try doing, in the cm3 directory: touch m3-sys/m3gdb/gdb/gdb/ada-lex.c and rebuilding. -- ------------------------------------------------------------- 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 Tue Aug 14 09:43:55 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Aug 2007 09:43:55 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> On Tue, August 14, 2007 05:55, Alex Bochannek wrote: > Olaf, > > "Olaf Wagner" writes: > >> I would be surprised if that would be all; supporting other installation >> locations by the simple build scripts has really not been a target >> until now. Improvements are always welcome though, so if you have >> patches that make this abstraction they're sure to get included. > > I don't really know my way around the CM3 install scripts very well, but > I am happy to have a look and see what I can come up with. > >> cm3cg is the standard GNU compiler backend, so it may need some >> (ever increasing) infrastructure (i.e. other GNU libraries). We should >> either declare this as an explicit dependency (i.e. installation >> prerequisite) or include it in our installation archives. Probably >> it hasn't been missing for anybody else using M3 so far, because >> gcc was always installed before. > > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. Could/should I use > EZM3 to bootstrap CM3? Sounds like a good idea; we should probably add --disable-nls to our gcc configuration. I don't think it will be easy to bootstrap CM3 with EZM3 (though it should be possible); there will probably be some subtle dependencies one tends to overlook. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Thu Aug 16 09:03:36 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 09:03:36 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> Message-ID: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 07:37, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Sounds like a good idea; we should probably add --disable-nls to >> our gcc configuration. > > If you want to build a SOLgnu installation archive, I would be happy to > test it. > > I have been looking at building CM3 on a recent RHEL-like Linux > distribution. It seems that for the 5.4.0 release, it will build and > ship if the two known issues are taken care of (the adm/ipc.h and the > LD_POINTER_GUARD). > > However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 > installation archive seems to not be possible anymore. I followed the > email exchanges with Tony Hosking's suggested build steps and also made > the PTHREAD and GC related changes necessary to cm3.cfg. After numerous > errors due to what I think are the LONGINT changes, I gave up. I don't > really need these changes, but it looks like it might be time for > another release soon. Sure, as soon as the LONGINT changes have settled, we'll provide some new installation archives. Stefan, could you add the --disable-nls to the gcc configuration and try to build a SOLgnu archive? Thanks, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Thu Aug 16 12:22:25 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:22:25 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: <20070816102225.GA25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? Current head, 5.4, or both? -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 12:59:22 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 12:59:22 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816102225.GA25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> Message-ID: <20070816105922.GB25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: > > Stefan, could you add the --disable-nls to the gcc configuration and > > try to build a SOLgnu archive? > > Current head, 5.4, or both? Wait a minute... as far as I can tell we already build it with --disable-nls in all cases. Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk has the same): % configure the sources if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "--with-gnu-ld=yes", "&& echo \"done\" > " & done) else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end else exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--target=" & GNU_platform (M3CC_TARGET), "--enable-languages=m3cg", "--disable-nls", "&& echo \"done\" > " & done) end end -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Thu Aug 16 14:54:34 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 16 Aug 2007 14:54:34 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816105922.GB25938@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> Message-ID: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 12:59, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 12:22:25PM +0200, Stefan Sperling wrote: >> On Thu, Aug 16, 2007 at 09:03:36AM +0200, Olaf Wagner wrote: >> > Stefan, could you add the --disable-nls to the gcc configuration and >> > try to build a SOLgnu archive? >> >> Current head, 5.4, or both? Both :) > Wait a minute... as far as I can tell we already build it > with --disable-nls in all cases. > > Quoting m3-sys/m3cc/src/m3makefile from the 5.4 branch (trunk > has the same): > > % configure the sources > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "--with-gnu-ld=yes", > "&& echo \"done\" > " & done) > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > else > exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--target=" & GNU_platform (M3CC_TARGET), > "--enable-languages=m3cg", > "--disable-nls", > "&& echo \"done\" > " & done) > end > end Then I don't understand why the version Alex Bochannek got from our installation archives needed libiconv.so.2. Any idea? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Thu Aug 16 15:42:53 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:42:53 -0400 Subject: [M3devel] Windows Message-ID: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> With the current native Windows backend (m3back) blindly assuming (without even checking!) that all integer operations are 32-bit, I wonder if anyone out there has the expertise, time, or inclination to smarten it up to handle both 32-bit and 64-bit ops. It should not be *too* hard, but I don't have the time for it now, though I would be happy to answer any questions that arise. Unfortunately, this reveals that Windows support is withering on the vine, in spite of Jay's excellent recent work. As of now, this means that Windows can only build CVS sources with the tag devel_LONGINT_start. Bridging the gap will require smartening up m3back or using the gcc-based backend. From stsp at elego.de Thu Aug 16 15:44:59 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 15:44:59 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> <20070816102225.GA25938@jack.stsp.lan> <20070816105922.GB25938@jack.stsp.lan> <64229.194.138.127.36.1187268874.squirrel@mail.elegosoft.com> Message-ID: <20070816134458.GD25938@jack.stsp.lan> On Thu, Aug 16, 2007 at 02:54:34PM +0200, Olaf Wagner wrote: > Then I don't understand why the version Alex Bochannek got from > our installation archives needed libiconv.so.2. Any idea? Because m3-sys/m3cc/gcc/gcc/configure.ac depends on it unconditionally. The following is in global scope: AM_ICONV # Until we have in-tree GNU iconv: LIBICONV_DEP= AC_SUBST(LIBICONV_DEP) So I guess the configure script always picks up libiconv if it is present. I'll try to remove the check for libiconv to see if the backend builds without it. The script even bothers to filter out possible multiple occurences of -liconv if --enable-nls is passed (i.e. gcc if is linked to libintl): # If LIBINTL contains LIBICONV, then clear LIBICONV so we don't get # -liconv on the link line twice. case "$LIBINTL" in *$LIBICONV*) LIBICONV= ;; esac The non-iconv case is clearly not intended by the authors of configure.ac... Also, I just checked the cm3cg binary on FreeBSD, it also depends on libiconv, which is not in the base system on FreeBSD either: % ldd /usr/local/cm3/bin/cm3cg /usr/local/cm3/bin/cm3cg: libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28474000) libc.so.6 => /lib/libc.so.6 (0x28561000) -- stefan http://stsp.name PGP Key: 0xF59D25F0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 15:34:51 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 09:34:51 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <48401.194.138.127.36.1187077435.squirrel@mail.elegosoft.com> <48262.194.138.127.36.1187247816.squirrel@mail.elegosoft.com> Message-ID: On Aug 16, 2007, at 3:03 AM, Olaf Wagner wrote: > On Thu, August 16, 2007 07:37, Alex Bochannek wrote: >> "Olaf Wagner" writes: >> >>> Sounds like a good idea; we should probably add --disable-nls to >>> our gcc configuration. >> >> If you want to build a SOLgnu installation archive, I would be >> happy to >> test it. I'm about to build from CVS head for SOLgnu today. I will place a bootstrap compiler (front-end and back-end) on my ftp site in the usual place. >> I have been looking at building CM3 on a recent RHEL-like Linux >> distribution. It seems that for the 5.4.0 release, it will build and >> ship if the two known issues are taken care of (the adm/ipc.h and the >> LD_POINTER_GUARD). I don't know how these issues relate to the CVS head, but I did successfully bootstrap CVS head yesterday. The compiler pieces are in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6, files cm3cg.gz and cm3.gz. >> >> However, to bootstrap a top-of-tree CVS checkout with the 5.4.0 >> installation archive seems to not be possible anymore. I followed the >> email exchanges with Tony Hosking's suggested build steps and also >> made >> the PTHREAD and GC related changes necessary to cm3.cfg. After >> numerous >> errors due to what I think are the LONGINT changes, I gave up. I >> don't >> really need these changes, but it looks like it might be time for >> another release soon. Indeed, to bootstrap from an *old* compiler that does not handle LONGINT, you will need to build and ship in the following order: m3cc m3middle m3linker m3front m3quake cm3 Now, using the *new* stage 1 cm3 you just built (cm3/TARGET/cm3) and clean sources you can build and ship: m3core libm3 m3middle m3linker m3front m3quake cm3 With this *new* stage 2 cm3 you should be ready to build the world. > Sure, as soon as the LONGINT changes have settled, we'll provide some > new installation archives. Getting there... We really need someone to work on the *native* x86 backend m3back to smarten it up for LONGINT ... until then truly native Win32 support will be lacking (though it should be possible to build using the gcc-based backend, presumably installed and built using CygWin?). > Stefan, could you add the --disable-nls to the gcc configuration and > try to build a SOLgnu archive? I'll put a SOLgnu bootstrap compiler built from the CVS head on my ftp site later today. > > Thanks, > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 > 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 From rodney.bates at wichita.edu Thu Aug 16 18:19:39 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 11:19:39 -0500 Subject: [M3devel] Missing .M3EXPORTS Message-ID: <46C4791B.1080207@wichita.edu> What does the following failure mean? I run into it regularly. -------------------------------------------------------------------------------------------------- rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build --- building in LINUXLIBC6 --- ignoring ../src/m3overrides "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading --procedure-- -line- -file--- import_version -- import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/src/m3makefile 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/m3middle/LINUXLIBC6/m3make.args Fatal Error: package build failed -------------------------------------------------------------------------------------------------- Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp site into /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library locations and -gstabs to m3-link. I did a cvs update for the whole cm3 head, then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 -build and cm3 -ship. -- ------------------------------------------------------------- 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 Thu Aug 16 18:33:20 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:33:20 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4791B.1080207@wichita.edu> References: <46C4791B.1080207@wichita.edu> Message-ID: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > What does the following failure mean? I run into it regularly. > > ---------------------------------------------------------------------- > ---------------------------- > rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build > --- building in LINUXLIBC6 --- > > ignoring ../src/m3overrides > > "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake > runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ > m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading > > --procedure-- -line- -file--- > import_version -- > import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS > include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/src/m3makefile > 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ > m3middle/LINUXLIBC6/m3make.args > > Fatal Error: package build failed > > ---------------------------------------------------------------------- > ---------------------------- > > Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's > ftp site into > /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my > library > locations and -gstabs to m3-link. I did a cvs update for the whole > cm3 head, > then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - > build and cm3 -ship. > > -- > ------------------------------------------------------------- > 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 Thu Aug 16 18:47:36 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 12:47:36 -0400 Subject: [M3devel] Windows In-Reply-To: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> References: <98EEC9F9-6CF5-4228-885C-F247A4F7B62A@cs.purdue.edu> Message-ID: I should have realized of course that there is a very simple fix for compilation on the NT386 target using the native m3back backend! Simply make LONGINT=Int32. Jay, I have just checked in this very simple fix to Target.m3 which should permit you to bootstrap a new cm3 and compile the current CVS head. On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > With the current native Windows backend (m3back) blindly assuming > (without even checking!) that all integer operations are 32-bit, I > wonder if anyone out there has the expertise, time, or inclination > to smarten it up to handle both 32-bit and 64-bit ops. It should > not be *too* hard, but I don't have the time for it now, though I > would be happy to answer any questions that arise. Unfortunately, > this reveals that Windows support is withering on the vine, in > spite of Jay's excellent recent work. As of now, this means that > Windows can only build CVS sources with the tag > devel_LONGINT_start. Bridging the gap will require smartening up > m3back or using the gcc-based backend. > From hosking at cs.purdue.edu Thu Aug 16 19:13:06 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:13:06 -0400 Subject: [M3devel] AMD64 Message-ID: I seem to recall that someone had been working on a Linux AMD64 target. I'd like to get that working and would be interested in any progress that's been made in that direction. From stsp at elego.de Thu Aug 16 19:25:15 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:25:15 +0200 Subject: [M3devel] AMD64 In-Reply-To: References: Message-ID: <20070816172515.GC15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:18:13 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:18:13 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816171813.GB15579@jack.stsp.lan> A non-text attachment was scrubbed... Name: not available Type: multipart/signed Size: 30 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:46:55 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:46:55 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> Message-ID: <20070816174655.GD15579@jack.stsp.lan> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: > Is it possible to configure it with --disable-nls? That's what we tend > to do for our GCC builds as well. I just looked at the EZM3 install we > have and it doesn't seem like it requires libiconv. I'd favour listing libiconv as an explicit dependency of cm3. I've looked into this, and --disable-nls is not sufficient to remove gcc's dependency on libiconv. It unconditionally depends on libiconv if it can find the library on the system, regardless of flags passed to the configure script. I've tried hacking iconv detection out of the build system. There's a diff below against cm3-5.4 that removes cm3cg's dependency on libiconv. But it is very ugly. m3gdb also unconditionally depends on libiconv. I have not looked into that. I cannot deinstall libiconv on our Solaris box to prevent configure from picking it up because I don't have root, and I don't really think it's a good idea to begin with because removing the library would probably break a lot of dependencies. Alex, could you provide more details on what gcc backend you are using? Does the ezm3 equivalent of the cm3cg executable depend on libiconv? % ldd /usr/local/cm3/bin/cm3cg libiconv.so.2 => /usr/local/lib/libiconv.so.2 libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 With the patch below I get: % ldd /usr/stsp/cm3/bin/cm3cg libc.so.1 => /lib/libc.so.1 libdl.so.1 => /lib/libdl.so.1 /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 Index: src/m3makefile =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v retrieving revision 1.16.2.1 diff -u -r1.16.2.1 m3makefile --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 @@ -126,7 +126,8 @@ if stale(donep, donep) if equal (M3CC_HOST, M3CC_TARGET) if equal (M3CC_TARGET, "SOLgnu") - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & "configure", + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." + & SL & "gcc" & SL & "configure", M3CC_CONFIG, "--srcdir=.." & SL & "gcc", "--enable-languages=m3cg", Index: gcc/gcc/Makefile.in =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v retrieving revision 1.6 diff -u -r1.6 Makefile.in --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 @@ -471,8 +471,8 @@ LIBINTL_DEP = @LIBINTL_DEP@ # Character encoding conversion library. -LIBICONV = @LIBICONV@ -LIBICONV_DEP = @LIBICONV_DEP@ +#LIBICONV = @LIBICONV@ +#LIBICONV_DEP = @LIBICONV_DEP@ # The GC method to be used on this system. GGC=@GGC at .o @@ -718,7 +718,7 @@ BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a # Dependencies on the intl and portability libraries. -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) # Likewise, for use in the tools that must run on this machine # even if we are cross-building GCC. @@ -726,7 +726,7 @@ # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 19:49:56 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:49:56 +0200 Subject: [M3devel] AMD64 In-Reply-To: <20070816172515.GC15579@jack.stsp.lan> References: <20070816172515.GC15579@jack.stsp.lan> Message-ID: <20070816174956.GE15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 07:25:15PM +0200, Stefan Sperling wrote: > <<< No Message Collected >>> > --oTHb8nViIGeoXxdp-- Sorry, local sendmail screw up. Manually messing with the mail queue is not a good idea :-/ Here is the message again: On Thu, Aug 16, 2007 at 01:13:06PM -0400, Tony Hosking wrote: > I seem to recall that someone had been working on a Linux AMD64 target. > I'd like to get that working and would be interested in any progress that's > been made in that direction. That was me. It was more than 2 years ago. The problem back then was that the gcc backend kept segfaulting while trying to bootstrap a native cm3 for amd64. The front end is pretty much done iirc. We anticipated an update of the backend to see if that would fix things. Since you've done the update long ago at this stage, I guess it's worth trying to merge the diff into the current tree, minus the now obsolete system call wrappers in the diff. Maybe things just work. The diff is here: http://www.stsp.name/cm3/cm3-linux-amd64-2005-04-18.patch -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 19:53:42 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:53:42 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816174655.GD15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> Message-ID: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> I just built cm3cg on SPARC: hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 hosking at arthur ~-> No libiconv... The bootstrap compiler (cm3) and backend (cm3cg) are available at ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and cm3cg.gz. These are both built from the CVS head and contain LONGINT support. On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >> Is it possible to configure it with --disable-nls? That's what we >> tend >> to do for our GCC builds as well. I just looked at the EZM3 >> install we >> have and it doesn't seem like it requires libiconv. > > I'd favour listing libiconv as an explicit dependency of cm3. > > I've looked into this, and --disable-nls is not sufficient to remove > gcc's dependency on libiconv. It unconditionally depends on libiconv > if it can find the library on the system, regardless of flags passed > to the configure script. > > I've tried hacking iconv detection out of the build system. > There's a diff below against cm3-5.4 that removes cm3cg's > dependency on libiconv. But it is very ugly. > > m3gdb also unconditionally depends on libiconv. > I have not looked into that. > > I cannot deinstall libiconv on our Solaris box to prevent configure > from picking it up because I don't have root, and I don't really think > it's a good idea to begin with because removing the library would > probably break a lot of dependencies. > > Alex, could you provide more details on what gcc backend you are > using? > Does the ezm3 equivalent of the cm3cg executable depend on libiconv? > > > % ldd /usr/local/cm3/bin/cm3cg > libiconv.so.2 => /usr/local/lib/libiconv.so.2 > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > With the patch below I get: > > % ldd /usr/stsp/cm3/bin/cm3cg > libc.so.1 => /lib/libc.so.1 > libdl.so.1 => /lib/libdl.so.1 > /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 > > > Index: src/m3makefile > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v > retrieving revision 1.16.2.1 > diff -u -r1.16.2.1 m3makefile > --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 > +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 > @@ -126,7 +126,8 @@ > if stale(donep, donep) > if equal (M3CC_HOST, M3CC_TARGET) > if equal (M3CC_TARGET, "SOLgnu") > - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & > "configure", > + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." > + & SL & "gcc" & SL & "configure", > M3CC_CONFIG, > "--srcdir=.." & SL & "gcc", > "--enable-languages=m3cg", > Index: gcc/gcc/Makefile.in > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v > retrieving revision 1.6 > diff -u -r1.6 Makefile.in > --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 > +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 > @@ -471,8 +471,8 @@ > LIBINTL_DEP = @LIBINTL_DEP@ > > # Character encoding conversion library. > -LIBICONV = @LIBICONV@ > -LIBICONV_DEP = @LIBICONV_DEP@ > +#LIBICONV = @LIBICONV@ > +#LIBICONV_DEP = @LIBICONV_DEP@ > > # The GC method to be used on this system. > GGC=@GGC at .o > @@ -718,7 +718,7 @@ > BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a > > # Dependencies on the intl and portability libraries. > -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) > +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) > > # Likewise, for use in the tools that must run on this machine > # even if we are cross-building GCC. > @@ -726,7 +726,7 @@ > > # How to link with both our special library facilities > # and the system's installed libraries. > -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) > +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) > > # Any system libraries needed just for GNAT. > SYSLIBS = @GNAT_LIBEXC@ > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From hosking at cs.purdue.edu Thu Aug 16 19:54:55 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 13:54:55 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: PS Here is how I configured building in m3cc/SOLgnu: ../gcc/configure --enable-languages=m3cg --disable-nls On Aug 16, 2007, at 1:53 PM, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... > > The bootstrap compiler (cm3) and backend (cm3cg) are available at > ftp://ftp.cs.purdue.edu/pub/hosking/m3/SOLgnu in files cm3.gz and > cm3cg.gz. These are both built from the CVS head and contain > LONGINT support. > > > On Aug 16, 2007, at 1:46 PM, Stefan Sperling wrote: > >> On Mon, Aug 13, 2007 at 08:55:01PM -0700, Alex Bochannek wrote: >>> Is it possible to configure it with --disable-nls? That's what we >>> tend >>> to do for our GCC builds as well. I just looked at the EZM3 >>> install we >>> have and it doesn't seem like it requires libiconv. >> >> I'd favour listing libiconv as an explicit dependency of cm3. >> >> I've looked into this, and --disable-nls is not sufficient to remove >> gcc's dependency on libiconv. It unconditionally depends on libiconv >> if it can find the library on the system, regardless of flags passed >> to the configure script. >> >> I've tried hacking iconv detection out of the build system. >> There's a diff below against cm3-5.4 that removes cm3cg's >> dependency on libiconv. But it is very ugly. >> >> m3gdb also unconditionally depends on libiconv. >> I have not looked into that. >> >> I cannot deinstall libiconv on our Solaris box to prevent configure >> from picking it up because I don't have root, and I don't really >> think >> it's a good idea to begin with because removing the library would >> probably break a lot of dependencies. >> >> Alex, could you provide more details on what gcc backend you are >> using? >> Does the ezm3 equivalent of the cm3cg executable depend on libiconv? >> >> >> % ldd /usr/local/cm3/bin/cm3cg >> libiconv.so.2 => /usr/local/lib/libiconv.so.2 >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> With the patch below I get: >> >> % ldd /usr/stsp/cm3/bin/cm3cg >> libc.so.1 => /lib/libc.so.1 >> libdl.so.1 => /lib/libdl.so.1 >> /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1 >> >> >> Index: src/m3makefile >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/src/m3makefile,v >> retrieving revision 1.16.2.1 >> diff -u -r1.16.2.1 m3makefile >> --- src/m3makefile 23 Aug 2006 14:24:27 -0000 1.16.2.1 >> +++ src/m3makefile 16 Aug 2007 17:27:18 -0000 >> @@ -126,7 +126,8 @@ >> if stale(donep, donep) >> if equal (M3CC_HOST, M3CC_TARGET) >> if equal (M3CC_TARGET, "SOLgnu") >> - exec ("cd", build_dir, "; .." & SL & "gcc" & SL & >> "configure", >> + exec ("cd", build_dir, "; env am_cv_lib_iconv=no .." >> + & SL & "gcc" & SL & "configure", >> M3CC_CONFIG, >> "--srcdir=.." & SL & "gcc", >> "--enable-languages=m3cg", >> Index: gcc/gcc/Makefile.in >> =================================================================== >> RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/Makefile.in,v >> retrieving revision 1.6 >> diff -u -r1.6 Makefile.in >> --- gcc/gcc/Makefile.in 10 Aug 2006 00:29:50 -0000 1.6 >> +++ gcc/gcc/Makefile.in 16 Aug 2007 17:27:18 -0000 >> @@ -471,8 +471,8 @@ >> LIBINTL_DEP = @LIBINTL_DEP@ >> >> # Character encoding conversion library. >> -LIBICONV = @LIBICONV@ >> -LIBICONV_DEP = @LIBICONV_DEP@ >> +#LIBICONV = @LIBICONV@ >> +#LIBICONV_DEP = @LIBICONV_DEP@ >> >> # The GC method to be used on this system. >> GGC=@GGC at .o >> @@ -718,7 +718,7 @@ >> BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a >> >> # Dependencies on the intl and portability libraries. >> -LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) $(LIBICONV_DEP) >> +LIBDEPS= $(LIBIBERTY) $(LIBINTL_DEP) #$(LIBICONV_DEP) >> >> # Likewise, for use in the tools that must run on this machine >> # even if we are cross-building GCC. >> @@ -726,7 +726,7 @@ >> >> # How to link with both our special library facilities >> # and the system's installed libraries. >> -LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) $(LIBICONV) >> +LIBS = @LIBS@ $(LIBIBERTY) $(LIBINTL) #$(LIBICONV) >> >> # Any system libraries needed just for GNAT. >> SYSLIBS = @GNAT_LIBEXC@ >> >> -- >> Stefan Sperling Software Developer >> elego Software Solutions GmbH HRB 77719 >> Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 >> 13355 Berlin Fax: +49 30 23 45 86 95 >> http://www.elego.de Geschaeftsfuehrer: Olaf Wagner > From stsp at elego.de Thu Aug 16 19:59:30 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 19:59:30 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816175930.GG15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: > I just built cm3cg on SPARC: > > hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg > libc.so.1 => /usr/lib/libc.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 > hosking at arthur ~-> > > No libiconv... Is that because you don't have libiconv installed on your system? -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stsp at elego.de Thu Aug 16 20:10:04 2007 From: stsp at elego.de (Stefan Sperling) Date: Thu, 16 Aug 2007 20:10:04 +0200 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <20070816181004.GH15579@jack.stsp.lan> On Thu, Aug 16, 2007 at 01:54:55PM -0400, Tony Hosking wrote: > PS Here is how I configured building in m3cc/SOLgnu: > > ../gcc/configure --enable-languages=m3cg --disable-nls --disable-nls makes no difference at all with respect to libiconv. See my previous mail. All --disable-nls does is remove a dependency on libintl. This is not a Solaris-only problem. We can either: 1) Build cm3 releases on boxes that haven't got libiconv installed. 2) Declare libiconv an official dependency of cm3. 3) Hack the dependency on libiconv out of the build systems of cm3cg and m3gdb, and possibly others. 1) is a pain for people making releases. 2) is easy for developers, and nothing changes for users because we've always implicitly depended on libiconv without noticing. I've posted a crude patch that does 3) for cm3cg, but not for m3gdb. -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From hosking at cs.purdue.edu Thu Aug 16 20:28:56 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 14:28:56 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: <20070816175930.GG15579@jack.stsp.lan> References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <20070816175930.GG15579@jack.stsp.lan> Message-ID: On Aug 16, 2007, at 1:59 PM, Stefan Sperling wrote: > On Thu, Aug 16, 2007 at 01:53:42PM -0400, Tony Hosking wrote: >> I just built cm3cg on SPARC: >> >> hosking at arthur ~-> ldd /p/sss/cm3/bin/cm3cg >> libc.so.1 => /usr/lib/libc.so.1 >> libdl.so.1 => /usr/lib/libdl.so.1 >> /usr/platform/SUNW,Sun-Fire-V250/lib/libc_psr.so.1 >> hosking at arthur ~-> >> >> No libiconv... > > Is that because you don't have libiconv installed on your system? Hmm. The version of gcc I built cm3cg with was bootstrapped from a configuration: ../gcc/configure --prefix=/p/sss/gcc-4.1 --enable-languages=c On inspection, it appears that there is no libiconv installed in /p/ sss/gcc-4.1/lib. hosking at arthur ~-> ls -l /p/sss/gcc-4.1/lib total 2280 drwxr-sr-x 3 hosking sssadmin 4096 Aug 16 12:48 gcc/ lrwxrwxrwx 1 hosking sssadmin 13 Aug 16 12:49 libgcc_s.so -> libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 234060 Aug 16 12:49 libgcc_s.so.1 -rw-r--r-- 1 hosking sssadmin 816456 Aug 16 12:49 libiberty.a -rw-r--r-- 1 hosking sssadmin 47164 Aug 16 12:49 libssp.a -rwxr-xr-x 1 hosking sssadmin 732 Aug 16 12:49 libssp.la* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so -> libssp.so.0.0.0* lrwxrwxrwx 1 hosking sssadmin 15 Aug 16 12:49 libssp.so.0 -> libssp.so.0.0.0* -rwxr-xr-x 1 hosking sssadmin 29060 Aug 16 12:49 libssp.so.0.0.0* -rw-r--r-- 1 hosking sssadmin 2200 Aug 16 12:49 libssp_nonshared.a -rwxr-xr-x 1 hosking sssadmin 714 Aug 16 12:49 libssp_nonshared.la* drwxr-sr-x 2 hosking sssadmin 4096 Aug 16 12:49 sparcv9/ hosking at arthur ~-> > > -- > Stefan Sperling Software Developer > elego Software Solutions GmbH HRB 77719 > Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 > 13355 Berlin Fax: +49 30 23 45 86 95 > http://www.elego.de Geschaeftsfuehrer: Olaf Wagner From rodney.bates at wichita.edu Thu Aug 16 22:49:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 15:49:08 -0500 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> Message-ID: <46C4B844.3080901@wichita.edu> No, I hadn't, but it didn't help. Note it is in m3core that the .M3EXPORTS is not found, while I was trying to compile in m3middle. In any case, it should be normal to do a compile in a directory that has a partially populated LINUXLIBC6 (or whatever), expecting the compiler to figure out what to do. I tried departing from the listed order and building/shipping m3core and libm3, before m3middle, and that got the bootstrap going. These did not have a LINUXLIBC6 directory, I suppose because of the realclean. Tony Hosking wrote: > Did you "rm -rf LINUXLIBC6" before "cm3 -build"? > > On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: > >> What does the following failure mean? I run into it regularly. >> >> ---------------------------------------------------------------------- >> ---------------------------- >> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >> --- building in LINUXLIBC6 --- >> >> ignoring ../src/m3overrides >> >> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/cm3/ >> m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >> >> --procedure-- -line- -file--- >> import_version -- >> import 4 /usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS >> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/src/m3makefile >> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >> m3middle/LINUXLIBC6/m3make.args >> >> Fatal Error: package build failed >> >> ---------------------------------------------------------------------- >> ---------------------------- >> >> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's ftp >> site into >> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my library >> locations and -gstabs to m3-link. I did a cvs update for the whole >> cm3 head, >> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - build >> and cm3 -ship. >> >> -- >> ------------------------------------------------------------- >> Rodney M. Bates, retired assistant professor >> Dept. of Computer Science, Wichita State University >> Wichita, KS 67260-0083 >> 316-978-3922 >> rodney.bates at wichita.edu > > > -- ------------------------------------------------------------- Rodney M. Bates, retired assistant professor Dept. of Computer Science, Wichita State University Wichita, KS 67260-0083 316-978-3922 rodney.bates at wichita.edu From rodney.bates at wichita.edu Thu Aug 16 23:19:08 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Thu, 16 Aug 2007 16:19:08 -0500 Subject: [M3devel] A strange link time warning using cm3 Message-ID: <46C4BF4C.9070706@wichita.edu> When linking a program of my own, using cm3 from the cvs head, I get this warning: ----------------------------------------------------------------------------------------------------- -> linking LdlBatch /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In function `TrestleOS__UserName': /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ----------------------------------------------------------------------------------------------------- And a few more just like it. This doesn't make any sense to me. If a "statically linked application" is what it says it is, why would it require at runtime, any shared library at all, let alone a specific version? -- ------------------------------------------------------------- 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 Thu Aug 16 23:26:47 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 16 Aug 2007 17:26:47 -0400 Subject: [M3devel] Missing .M3EXPORTS In-Reply-To: <46C4B844.3080901@wichita.edu> References: <46C4791B.1080207@wichita.edu> <82B6592D-6724-46C5-B26F-3FFE3EBB23F7@cs.purdue.edu> <46C4B844.3080901@wichita.edu> Message-ID: Sounds like you are getting overrides or something. Certainly is strange behavior, which I don't see. On Aug 16, 2007, at 4:49 PM, Rodney M. Bates wrote: > No, I hadn't, but it didn't help. Note it is in m3core that the > .M3EXPORTS is not found, while I was trying to compile in m3middle. > > In any case, it should be normal to do a compile in a directory > that has a partially populated LINUXLIBC6 (or whatever), expecting > the compiler to figure out what to do. > > I tried departing from the listed order and building/shipping > m3core and libm3, before m3middle, and that got the bootstrap > going. These did not have a LINUXLIBC6 directory, I suppose > because of the realclean. > > Tony Hosking wrote: >> Did you "rm -rf LINUXLIBC6" before "cm3 -build"? >> On Aug 16, 2007, at 12:19 PM, Rodney M. Bates wrote: >>> What does the following failure mean? I run into it regularly. >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> rodney at runnymede:~/proj/m3/cm3-fresh/cm3/m3-sys/m3middle$ cm3 -build >>> --- building in LINUXLIBC6 --- >>> >>> ignoring ../src/m3overrides >>> >>> "/usr/local/cm3/pkg/libm3/LINUXLIBC6/.M3EXPORTS", line 4: quake >>> runtime error: unable to open "/home/rodney/proj/m3/cm3-fresh/ >>> cm3/ m3-libs/m3core/LINUXLIBC6/.M3EXPORTS" for reading >>> >>> --procedure-- -line- -file--- >>> import_version -- >>> import 4 /usr/local/cm3/pkg/libm3/ >>> LINUXLIBC6/.M3EXPORTS >>> include_dir 11 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/src/m3makefile >>> 4 /home/rodney/proj/m3/cm3-fresh/cm3/m3-sys/ >>> m3middle/LINUXLIBC6/m3make.args >>> >>> Fatal Error: package build failed >>> >>> -------------------------------------------------------------------- >>> -- ---------------------------- >>> >>> Prior to this, I copied in cm3, cm3cg, and cm3.cfg from antony's >>> ftp site into >>> /usr/local/cm3/bin. I did a couple of tweaks to cm3.cfg for my >>> library >>> locations and -gstabs to m3-link. I did a cvs update for the >>> whole cm3 head, >>> then did scripts/do-cm3-std.sh realclean. In m3cc, I did cm3 - >>> build and cm3 -ship. >>> >>> -- >>> ------------------------------------------------------------- >>> Rodney M. Bates, retired assistant professor >>> Dept. of Computer Science, Wichita State University >>> Wichita, KS 67260-0083 >>> 316-978-3922 >>> rodney.bates at wichita.edu > > -- > ------------------------------------------------------------- > Rodney M. Bates, retired assistant professor > Dept. of Computer Science, Wichita State University > Wichita, KS 67260-0083 > 316-978-3922 > rodney.bates at wichita.edu From roland.illig at gmx.de Fri Aug 17 00:26:48 2007 From: roland.illig at gmx.de (Roland Illig) Date: Fri, 17 Aug 2007 00:26:48 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <46C4CF28.8090001@gmx.de> Rodney M. Bates wrote: > This doesn't make any sense to me. If a "statically linked > application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? The user, group, host, whatever databases uses a plug-in mechanism on Linux (something called nsswitch or similar). The plug-ins can be an SQL database, LDAP, PAM, traditional password files and so on. Since the exact set of plug-ins is not known at compile-time, shared libraries must be used in this case. Roland From wagner at elegosoft.com Fri Aug 17 09:54:42 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 09:54:42 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C4BF4C.9070706@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> Message-ID: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> On Thu, August 16, 2007 23:19, Rodney M. Bates wrote: > When linking a program of my own, using cm3 from the cvs head, I get this > warning: > ----------------------------------------------------------------------------------------------------- > -> linking LdlBatch > /usr/local/cm3/pkg/ui/LINUXLIBC6/libm3ui.a(TrestleOS.mo)(.text+0x177): In > function > `TrestleOS__UserName': > /home/rodney/proj/m3/cm3-fresh/cm3/m3-ui/ui/LINUXLIBC6/TrestleOS.m3:32: > warning: Using 'getpwuid' in > statically linked applications requires at runtime the shared libraries from > the glibc version used > for linking > ----------------------------------------------------------------------------------------------------- > > And a few more just like it. This doesn't make any sense to me. If a > "statically > linked application" is what it says it is, why would it require at runtime, > any shared library at all, let alone a specific version? As Roland Illig already pointed out, modern operating systems don't really support traditional static linking if you are using certain functionality (which accidentally is needed by almost all programs ;-). Nonetheless the warnings you get point to a problem with the CM3 setup: those libraries that need to be plugged-in by the OS must not be linked statically. In cm3.cfg the set up system libraries should be separated into those that need dynamic linking and others. All system libraries that need dynamic linking should be linked this way, regardless of the cm3 arguments. This way `statically linked' refers only to the CM3 libraries and not to the -- always available -- operating system libraries, and can still be a help for delivering independent programs written in M3. Stefan, I thought we had resolved this issue at least for Linux and Solaris setups with the last release. Did we miss something? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From stsp at elego.de Fri Aug 17 14:19:02 2007 From: stsp at elego.de (Stefan Sperling) Date: Fri, 17 Aug 2007 14:19:02 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> Message-ID: <20070817121902.GB10092@jack.stsp.lan> On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: > Stefan, I thought we had resolved this issue at least for Linux and > Solaris setups with the last release. Did we miss something? We link system libraries dynamically on these platforms. It could be that Rodney's own program does not link libraries dynamically, so he gets the warning. This is the diff that introduced dynamic linking on Linux. Note that we explicitly enable dynamic linking on a per-library basis... maybe we should enforce dynamic linking in general? Index: LINUXLIBC6 =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cm3/src/config/LINUXLIBC6,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- LINUXLIBC6 6 Aug 2006 12:46:03 -0000 1.7 +++ LINUXLIBC6 1 Sep 2006 13:42:23 -0000 1.8 @@ -98,14 +98,14 @@ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], -% "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms - "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], - "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], - "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], - "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], - "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", +% "LEX-YACC" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-ll" ], %-- not on most Linux platforms + "FLEX-BISON" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lfl" ], + "POSTGRES95" : [ "-Xlinker", "-Bdynamic", "-L/usr/local/postgres95/lib", "-lpq" ], + "OPENGL" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], + "MOTIF" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXm" ], + "X11" : [ "-Xlinker", "-Bdynamic", "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], - "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], + "PTHREAD" : [ "-Xlinker", "-Bdynamic", "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } -- Stefan Sperling Software Developer elego Software Solutions GmbH HRB 77719 Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96 13355 Berlin Fax: +49 30 23 45 86 95 http://www.elego.de Geschaeftsfuehrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From wagner at elegosoft.com Fri Aug 17 14:54:04 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 17 Aug 2007 14:54:04 +0200 (CEST) Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <20070817121902.GB10092@jack.stsp.lan> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> Message-ID: <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> Stefan, I thought we had resolved this issue at least for Linux and >> Solaris setups with the last release. Did we miss something? > > We link system libraries dynamically on these platforms. > > It could be that Rodney's own program does not link > libraries dynamically, so he gets the warning. > > This is the diff that introduced dynamic linking on Linux. > Note that we explicitly enable dynamic linking on a per-library > basis... maybe we should enforce dynamic linking in general? [diff removed] No, I only want to find out why Rodney gets those warnings. Either he hasn't the cm3.cfg changes from the last release, or some other packages (Trestle?) import more libraries which cause the problem. Rodney, could you please check that? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From rodney.bates at wichita.edu Fri Aug 17 22:26:02 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Fri, 17 Aug 2007 15:26:02 -0500 Subject: [M3devel] A strange link time warning using cm3] Message-ID: <46C6045A.6050402@wichita.edu> I usually just manually edit my old cm3.cfg files, because I usually have to merge my local library locations, etc. And I haven't done a cminstall in a while. So I don't have the official version. Right now, I have none of the libraries dynamically linked. I just didn't realize there were some of them that would not work on. From my cm3.cfg on the machine where I got the quoted message (running Linux Mandrake 10.2): ------------------------------------------------------------------------ SYSTEM_LIBS = { "LIBC" : [ "-lm" ], % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", "-lXt", "-lSM", "-lICE", "-lX11" ], "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], "TCP" : [ ] } ------------------------------------------------------------------------ Even so, the warning only happens when I compile a program with build_standalone ( ) in the m3makefile. I guess I'll put back the -Xlinker -Bdynamic in the libraries that Stefan's diff shows. Will this change anything other than getting rid of the warning message? After I read about dynamic linking in the 60's on the Multics system, I always thought it was a great idea. After decades of waiting, I gave up ever seeing it in anything but a research OS. Now that it has become universal, I have often wondered if we would be better to put that genie back in the bottle. Library version skew, when moving from machine to machine can be a nightmare, even when your OS does allow multiple versions to be installed simultaneously. But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. Olaf Wagner wrote: > On Fri, August 17, 2007 14:19, Stefan Sperling wrote: > >>On Fri, Aug 17, 2007 at 09:54:42AM +0200, Olaf Wagner wrote: >> >>>Stefan, I thought we had resolved this issue at least for Linux and >>>Solaris setups with the last release. Did we miss something? >> >>We link system libraries dynamically on these platforms. >> >>It could be that Rodney's own program does not link >>libraries dynamically, so he gets the warning. >> >>This is the diff that introduced dynamic linking on Linux. >>Note that we explicitly enable dynamic linking on a per-library >>basis... maybe we should enforce dynamic linking in general? > > [diff removed] > > No, I only want to find out why Rodney gets those warnings. > Either he hasn't the cm3.cfg changes from the last release, or > some other packages (Trestle?) import more libraries which cause > the problem. Rodney, could you please check that? > > Olaf -- ------------------------------------------------------------- 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 rcoleburn at scires.com Fri Aug 17 23:26:20 2007 From: rcoleburn at scires.com (Randy Coleburn) Date: Fri, 17 Aug 2007 17:26:20 -0400 Subject: [M3devel] A strange link time warning using cm3] In-Reply-To: <46C6045A.6050402@wichita.edu> References: <46C6045A.6050402@wichita.edu> Message-ID: <46C5DA31.1E75.00D7.1@scires.com> >>> "Rodney M. Bates" rodney.bates at wichita.edu> 8/17/2007 4:26 PM >> ( mailto:rodney.bates at wichita.edu> ) .... But at least, I thought, the option to do full static linking was still there, for those who chose it. So it is a bit of a shock to learn that that option is now gone. .... I thought that the buildstandalone() directive in the m3makefile is supposed to cause linking with static libraries. At least that is what happens in cm3 v4.1. Regards, Randy Randy C. Coleburn, CISSP Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE) Corporate & Atlanta Information Systems Security Manager (ISSM) Scientific Research Corporation 2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339 voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497 Quality Policy: "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements." -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sat Aug 18 02:47:36 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 02:47:36 +0200 Subject: [M3devel] strange... Message-ID: <1187398056.31487.17.camel@faramir.m3w.org> I am getting this... No idea where it gosts imported, and being so late here... Maybe I can find answer when I woke :). TIA. As far as I know, this is full boostrap by latest instructions from cvshead over earlier revision. ... -> linking hcca /usr/bin/ld: cannot find -lm3gcdefs collect2: ld returned 1 exit status Fatal Error: package build failed -- Dragi?a Duri? From jayk123 at hotmail.com Sat Aug 18 04:37:22 2007 From: jayk123 at hotmail.com (j k) Date: Sat, 18 Aug 2007 02:37:22 +0000 Subject: [M3devel] Windows Message-ID: I have the inclination, still working on time and expertise. :) Summarize the layering for me? Which module calls which?Your mention below of the assumption of 32 bit ops at least confirms what I thought I vaguely understood reading through the source. It's just a bunch of pretty dense code without documentation, the sort I write myself when I have the whole program in my head and just need to type it all in as quickly as possible. Would the idea be to use a tagged union for this stack, or to split 64 bits ops into pairs of 32 bit ops? You know, like, does this stack translate "closely" to the generated code, or not? If it does, pairs, if it does not, tagged union. Probably. Similarly, like, all the register dealings need some notion of pairs..? Maybe I should look at the other backend to understand better, if there is an analogous bunch of code. Anyway, I'll try at least this weekend to verify that it's buildable asis, i know that's just a teeny tiny baby step, just push the button to build, a monkey could do it... my expertise is beyond that, but... I suspect tagged union is it, and have to churn a bunch of code to check the type. ugh. lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 bit type). ?? Thanks, - Jay > CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: Windows> Date: Thu, 16 Aug 2007 12:47:36 -0400> To: jay.krell at cornell.edu; jayk123 at hotmail.com> > I should have realized of course that there is a very simple fix for > compilation on the NT386 target using the native m3back backend! > Simply make LONGINT=Int32. Jay, I have just checked in this very > simple fix to Target.m3 which should permit you to bootstrap a new > cm3 and compile the current CVS head.> > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote:> > > With the current native Windows backend (m3back) blindly assuming > > (without even checking!) that all integer operations are 32-bit, I > > wonder if anyone out there has the expertise, time, or inclination > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > not be *too* hard, but I don't have the time for it now, though I > > would be happy to answer any questions that arise. Unfortunately, > > this reveals that Windows support is withering on the vine, in > > spite of Jay's excellent recent work. As of now, this means that > > Windows can only build CVS sources with the tag > > devel_LONGINT_start. Bridging the gap will require smartening up > > m3back or using the gcc-based backend.> >> _________________________________________________________________ See what you?re getting into?before you go there http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Aug 18 11:52:52 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 18 Aug 2007 11:52:52 +0200 Subject: [M3devel] A strange link time warning using cm3 In-Reply-To: <46C5C599.9010306@wichita.edu> References: <46C4BF4C.9070706@wichita.edu> <48131.194.138.127.36.1187337282.squirrel@mail.elegosoft.com> <20070817121902.GB10092@jack.stsp.lan> <61149.194.138.127.36.1187355244.squirrel@mail.elegosoft.com> <46C5C599.9010306@wichita.edu> Message-ID: <20070818095252.GA10785@elegosoft.com> On Fri, Aug 17, 2007 at 10:58:17AM -0500, Rodney M. Bates wrote: > I usually just manually edit my old cm3.cfg files, because I usually > have to merge my local library locations, etc. And I haven't done a > cminstall in a while. So I don't have the official version. > > Right now, I have none of the libraries dynamically linked. I just > didn't realize there were some of them that would not work on. > > From my cm3.cfg on the machine where I got the quoted message > (running Linux Mandrake 10.2): > > ------------------------------------------------------------------------ > SYSTEM_LIBS = { > "LIBC" : [ "-lm" ], > % "LEX-YACC" : [ "-L/usr/lib", "-ll" ], %-- not on most Linux platforms > "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ], > "POSTGRES95" : [ "-L/usr/local/postgres95/lib", "-lpq" ], > "OPENGL" : [ "-L/usr/lib", "-lGLU", "-lGL", "-lXext" ], > "MOTIF" : [ "-L/usr/X11R6/lib", "-lXm" ], > "X11" : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext", > "-lXt", "-lSM", "-lICE", "-lX11" ], > "PTHREAD" : [ "-L/usr/lib", "-lpthread" ], > "TCP" : [ ] > } > ------------------------------------------------------------------------ OK, so you're just missing the dynamic hints in the linker setup. Could you please verify that that's all and we've found everything that needs to be linker dynamically unconditionally? > Even so, the warning only happens when I compile a program with > build_standalone ( ) in the m3makefile. The default has long been to link dynamically; build_standalone should switch to static linking wherever possible. > I guess I'll put back the -Xlinker -Bdynamic in the libraries that > Stefan's diff shows. Will this change anything other than getting > rid of the warning message? I hope not. > > After I read about dynamic linking in the 60's on the Multics system, > I always thought it was a great idea. After decades of waiting, I gave > up ever seeing it in anything but a research OS. Now that it has become > universal, I have often wondered if we would be better to put that genie > back in the bottle. Library version skew, when moving from machine to > machine can be a nightmare, even when your OS does allow multiple versions > to be installed simultaneously. But at least, I thought, the option to do > full static linking was still there, for those who chose it. So it is a > bit of a shock to learn that that option is now gone. > I'm with you there; I experienced the same feeling some years ago :-/ Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Sat Aug 18 19:35:17 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 18 Aug 2007 19:35:17 +0200 Subject: [M3devel] strange... And also some CM3isms In-Reply-To: <1187398056.31487.17.camel@faramir.m3w.org> References: <1187398056.31487.17.camel@faramir.m3w.org> Message-ID: <1187458517.31487.21.camel@faramir.m3w.org> One of packages was left behind while rebuilding... Of course there is no m3gcdefs in cm4 cvshead... Long ago I remember reading about runtime errors being exceptions (in CM3) and also RETURN and EXIT.... Is there some example code on how to use this? On Sat, 2007-08-18 at 02:47 +0200, Dragi?a Duri? wrote: > I am getting this... No idea where it gosts imported, and being so late > here... Maybe I can find answer when I woke :). TIA. > > As far as I know, this is full boostrap by latest instructions from > cvshead over earlier revision. > > ... > -> linking hcca > /usr/bin/ld: cannot find -lm3gcdefs > collect2: ld returned 1 exit status > Fatal Error: package build failed > -- Dragi?a Duri? From hosking at cs.purdue.edu Sat Aug 18 22:18:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Aug 2007 16:18:09 -0400 Subject: [M3devel] Windows In-Reply-To: References: Message-ID: <835F3374-48D2-4785-A82B-87792B1A483C@cs.purdue.edu> On Aug 17, 2007, at 10:37 PM, j k wrote: > I have the inclination, still working on time and expertise. :) > Summarize the layering for me? Which module calls which? > Your mention below of the assumption of 32 bit ops at least > confirms what I thought I vaguely understood reading through the > source. It's just a bunch of pretty dense code without > documentation, the sort I write myself when I have the whole > program in my head and just need to type it all in as quickly as > possible. Would the idea be to use a tagged union for this stack, > or to split 64 bits ops into pairs of 32 bit ops? > You know, like, does this stack translate "closely" to the > generated code, or not? If it does, pairs, if it does not, tagged > union. Probably. Similarly, like, all the register dealings need > some notion of pairs..? Maybe I should look at the other backend to > understand better, if there is an analogous bunch of code. You'll notice that the M3CG interface has many ops that take ZType= [Int32, Word32, Int64, Word64]. Unfortunatly M3x86.m3 and Stackx86.m3 simply drop those types on the floor (or simply distinguishes Word32 from Int32). I don't know the m3back code well at all, so I have no idea how tough it might be to smarten it up for Int64/Word64. > Anyway, I'll try at least this weekend to verify that it's > buildable asis, i know that's just a teeny tiny baby step, just > push the button to build, a monkey could do it... my expertise is > beyond that, but... Should be fine now, though INTEGER and LONGINT are both 32-bits for NT386 target. > > I suspect tagged union is it, and have to churn a bunch of code to > check the type. ugh. > lots of "Is64" sprinkled, or GetSize (assuming some futuristic 128 > bit type). Not sure... > > ?? > > Thanks, > - Jay > > > > > CC: m3devel at elegosoft.com > > From: hosking at cs.purdue.edu > > Subject: Re: Windows > > Date: Thu, 16 Aug 2007 12:47:36 -0400 > > To: jay.krell at cornell.edu; jayk123 at hotmail.com > > > > I should have realized of course that there is a very simple fix for > > compilation on the NT386 target using the native m3back backend! > > Simply make LONGINT=Int32. Jay, I have just checked in this very > > simple fix to Target.m3 which should permit you to bootstrap a new > > cm3 and compile the current CVS head. > > > > On Aug 16, 2007, at 9:42 AM, Tony Hosking wrote: > > > > > With the current native Windows backend (m3back) blindly assuming > > > (without even checking!) that all integer operations are 32-bit, I > > > wonder if anyone out there has the expertise, time, or inclination > > > to smarten it up to handle both 32-bit and 64-bit ops. It should > > > not be *too* hard, but I don't have the time for it now, though I > > > would be happy to answer any questions that arise. Unfortunately, > > > this reveals that Windows support is withering on the vine, in > > > spite of Jay's excellent recent work. As of now, this means that > > > Windows can only build CVS sources with the tag > > > devel_LONGINT_start. Bridging the gap will require smartening up > > > m3back or using the gcc-based backend. > > > > > > > > See what you?re getting into?before you go there See it! From dragisha at m3w.org Mon Aug 20 14:01:23 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 20 Aug 2007 14:01:23 +0200 Subject: [M3devel] subrange or enum, with cvshead Message-ID: <1187611284.31487.42.camel@faramir.m3w.org> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 (skipping m3gdb, which I've reported earlier would not compile for me) I am getting this error when I try to rn one of programs that worked flawlessy few checkouts ago. *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/uid/Common/TimeStamp.m3", line 63 *** This is corresponding code: now := Time.Now() - epoch; >>> time := TRUNC(now); fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, LONGREAL), 8)); I've identified few other problems, but I suppose ther are all variations... -- Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:46:24 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:46:24 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: Hmmm. Are you using the most recent cm3cg, and a compiler bootstrapped with it? Also, I have not tested the LONGINT stuff extensively on AMD64 yet. Any chance you can diagnose the problem? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Mon Aug 20 17:59:19 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 11:59:19 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187611284.31487.42.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> Message-ID: I think I've tracked this down to Time.Now returning 0. Hmmm. How could this be? On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: > After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 > (skipping > m3gdb, which I've reported earlier would not compile for me) I am > getting this error when I try to rn one of programs that worked > flawlessy few checkouts ago. > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/uid/Common/TimeStamp.m3", line 63 > *** > > This is corresponding code: > > now := Time.Now() - epoch; >>>> time := TRUNC(now); > fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, > LONGREAL), 8)); > > I've identified few other problems, but I suppose ther are all > variations... > > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:04:49 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:04:49 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187635746.31487.50.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> Message-ID: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> I've figured out the cure, but don't know why the problem exists. It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE constants when built on AMD64, unless it is configured as: CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls --enable-targets=x86-linux If you omit CC="gcc -m32" then the problem arises. I have put my AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and do not represent a complete 64-bit port to AMD64. See cm3.cfg, cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/LINUXLIBC6- AMD64. On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > I've bootstrapped it same way as on ix86, first m3cc...cm3, then > setting > CM3 env var, then std build... > > When I just rsynced my INSTALL_ROOT and built binaries... it works, of > course. > > As for Time.Now()... I have few other problems happening... Do you > have > some kind of test code for LONGINT I can run on this AMD64 box? > > dd > > On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >> Hmmm. Are you using the most recent cm3cg, and a compiler >> bootstrapped with it? >> >> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >> Any chance you can diagnose the problem? >> >> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >> >>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>> (skipping >>> m3gdb, which I've reported earlier would not compile for me) I am >>> getting this error when I try to rn one of programs that worked >>> flawlessy few checkouts ago. >>> >>> *** >>> *** runtime error: >>> *** An enumeration or subrange value was out of range. >>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>> *** >>> >>> This is corresponding code: >>> >>> now := Time.Now() - epoch; >>>>>> time := TRUNC(now); >>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>> LONGREAL), 8)); >>> >>> I've identified few other problems, but I suppose ther are all >>> variations... >>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 01:30:43 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 20 Aug 2007 19:30:43 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> Message-ID: <27A835EB-4FA5-49B6-A30B-900361904CEF@cs.purdue.edu> PS I've successfully bootstrapped 32-bit LINUXLIBC6 on AMD64 and run mentor Bresenham using the bottstrap binaries from my ftp site. On Aug 20, 2007, at 7:04 PM, Tony Hosking wrote: > I've figured out the cure, but don't know why the problem exists. > It seems that the gcc-based backend builds incorrect FLOAT/DOUBLE > constants when built on AMD64, unless it is configured as: > > CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable- > nls --enable-targets=x86-linux > > If you omit CC="gcc -m32" then the problem arises. I have put my > AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the > directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, > and do not represent a complete 64-bit port to AMD64. See cm3.cfg, > cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ > LINUXLIBC6-AMD64. > > On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: > >> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >> setting >> CM3 env var, then std build... >> >> When I just rsynced my INSTALL_ROOT and built binaries... it >> works, of >> course. >> >> As for Time.Now()... I have few other problems happening... Do you >> have >> some kind of test code for LONGINT I can run on this AMD64 box? >> >> dd >> >> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>> Hmmm. Are you using the most recent cm3cg, and a compiler >>> bootstrapped with it? >>> >>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>> Any chance you can diagnose the problem? >>> >>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>> >>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>> (skipping >>>> m3gdb, which I've reported earlier would not compile for me) I am >>>> getting this error when I try to rn one of programs that worked >>>> flawlessy few checkouts ago. >>>> >>>> *** >>>> *** runtime error: >>>> *** An enumeration or subrange value was out of range. >>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>> *** >>>> >>>> This is corresponding code: >>>> >>>> now := Time.Now() - epoch; >>>>>>> time := TRUNC(now); >>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>> LONGREAL), 8)); >>>> >>>> I've identified few other problems, but I suppose ther are all >>>> variations... >>>> >>>> -- >>>> Dragi?a Duri? >>> >> -- >> Dragi?a Duri? > From wagner at elegosoft.com Tue Aug 21 08:57:47 2007 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 21 Aug 2007 08:57:47 +0200 (CEST) Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> On Tue, August 21, 2007 05:07, Alex Bochannek wrote: > I finally got around to completing a successful buildship on Solaris 10 > on SPARC. Here are the steps I did. > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) Without haveing investigated any of the issues above -- all this sounds to me like you are using a quite old Solaris system. I'd like to see the exact versions you and Tony use to build the software (uname -a). At least it might be a different worth to docuement. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 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 Aug 21 15:54:09 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:54:09 -0400 Subject: [M3devel] subrange or enum, with cvshead In-Reply-To: <1187674684.31487.54.camel@faramir.m3w.org> References: <1187611284.31487.42.camel@faramir.m3w.org> <1187635746.31487.50.camel@faramir.m3w.org> <4ED687F3-FB76-43D1-AEFE-A3BC512C8BEB@cs.purdue.edu> <1187674684.31487.54.camel@faramir.m3w.org> Message-ID: <0558ABE2-AEB9-42F0-8E62-A5B0A3E74BE7@cs.purdue.edu> I generally skip m3gdb. I haven't tried it on AMD64. On Aug 21, 2007, at 1:38 AM, Dragi?a Duri? wrote: > Can this be a problem with m3gdb not building, LINUXLIBC6 target on > AMD64? Is it built on your machine? > > dd > > On Mon, 2007-08-20 at 19:04 -0400, Tony Hosking wrote: >> I've figured out the cure, but don't know why the problem exists. It >> seems that the gcc-based backend builds incorrect FLOAT/DOUBLE >> constants when built on AMD64, unless it is configured as: >> >> CC="gcc -m32" ../gcc/configure --enable-languages=m3cg --disable-nls >> --enable-targets=x86-linux >> >> If you omit CC="gcc -m32" then the problem arises. I have put my >> AMD64 bootstrap executables for LINUXLIBC6 on my ftp site in the >> directory LINUXLIBC6-AMD64. Note, these are for a 32-bit target, and >> do not represent a complete 64-bit port to AMD64. See cm3.cfg, >> cm3.gz, cm3cg.gz in ftp://ftp.cs.purdue.edu/pub/hosking/m3/ >> LINUXLIBC6- >> AMD64. >> >> On Aug 20, 2007, at 2:49 PM, Dragi?a Duri? wrote: >> >>> I've bootstrapped it same way as on ix86, first m3cc...cm3, then >>> setting >>> CM3 env var, then std build... >>> >>> When I just rsynced my INSTALL_ROOT and built binaries... it >>> works, of >>> course. >>> >>> As for Time.Now()... I have few other problems happening... Do you >>> have >>> some kind of test code for LONGINT I can run on this AMD64 box? >>> >>> dd >>> >>> On Mon, 2007-08-20 at 11:46 -0400, Tony Hosking wrote: >>>> Hmmm. Are you using the most recent cm3cg, and a compiler >>>> bootstrapped with it? >>>> >>>> Also, I have not tested the LONGINT stuff extensively on AMD64 yet. >>>> Any chance you can diagnose the problem? >>>> >>>> On Aug 20, 2007, at 8:01 AM, Dragi?a Duri? wrote: >>>> >>>>> After I've compiled CM3 from cvshead for LINUXLIBC6 on x86_64 >>>>> (skipping >>>>> m3gdb, which I've reported earlier would not compile for me) I am >>>>> getting this error when I try to rn one of programs that worked >>>>> flawlessy few checkouts ago. >>>>> >>>>> *** >>>>> *** runtime error: >>>>> *** An enumeration or subrange value was out of range. >>>>> *** file "../src/uid/Common/TimeStamp.m3", line 63 >>>>> *** >>>>> >>>>> This is corresponding code: >>>>> >>>>> now := Time.Now() - epoch; >>>>>>>> time := TRUNC(now); >>>>> fineTime := ROUND(LongFloat.Scalb(now - FLOAT(time, >>>>> LONGREAL), 8)); >>>>> >>>>> I've identified few other problems, but I suppose ther are all >>>>> variations... >>>>> >>>>> -- >>>>> Dragi?a Duri? >>>> >>> -- >>> Dragi?a Duri? >> > -- > Dragi?a Duri? From hosking at cs.purdue.edu Tue Aug 21 15:59:01 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 09:59:01 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> Message-ID: <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> On Aug 20, 2007, at 11:07 PM, Alex Bochannek wrote: > I finally got around to completing a successful buildship on > Solaris 10 > on SPARC. Here are the steps I did. > > o Downloaded cm3-min-POSIX-SOLgnu-5.4.0.tgz and do a cminstall as root > into /usr/local/cm3 > > o In the process, some of the libraries it couldn't find I chose to > ignore (e.g., {PostgreSQL) > > o Downloaded the SOLgnu/cm3.gz and cm3cg.gz from Tony Hosking's site > > o Copied them over the existing ones in /usr/local/cm3 > > o Checked out a top-of-tree CVS version of cm3-src > > o Adjusted Tony's cm3.cfg to my INSTALL_ROOT > > o Did a scripts/do-cm3-core.sh buildship as root > > o Ran into all sorts of problems with make and ld and adjusted the > cm3.cfg to use GNU_MAKE = "gmake" and tweaked my PATH to use a > GNU ld > and an ar. (Sidenote: Incidentally, gcc configure uses > --print-prog-name=ld to figure out what ld to use for itself and > since > my installed gcc uses /usr/ccs/bin/ld I was concerned it wouldn't > work, but this isn't what is used later on anyway, so it didn't > matter.) > > o Ran into another problem with as and for some reason Tony's cm3.cfg > used /usr/ccs/bin/as, which chokes on the GNU as directives. Changed > cm3.cfg again. Which file chokes? Is it because your m3cc is configured to use GNU as? > > o do-cm3-core.sh completed and I did an install-cm3-compiler.sh > upgrade, > again as root since it's writing it into /usr/local/cm3 > > o Finally, did a do-cm3-std.sh buildship, which ran for quite a while. > > o Ran into compile problems with Gdb (looked like a C99 issue, but I > didn't investigate it further. Just ran a cm3 in m3gdb again and the > error is below.) > > o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh > buildship again. > > o The compile and install succeeded and I now have a nice new > cm3-d5.5.0. > > o Compiler some stuff in m3-games, just to make sure it really > works and > it looks like I am OK for now. I do see a number of core dumps > though > with some of apps, but I am not going to debug that at this point. What's core dumping? Is this from before my fixes to thread stopping yesterday? > > Thanks for the help and if there is anything I can do to help with > troubleshooting some of the problems on Solaris, I am happy to do so. > > Alex. > > > > Gdb compile error: > > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function version.c > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config - > DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../ > gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. -I../bfd - > I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl -I../../ > gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type - > Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith - > Wformat-nonliteral -Wunused-label -Wunused-function ../../gdb/gdb/ > valops.c > In file included from ../../gdb/gdb/m3-lang.h:23, > from ../../gdb/gdb/valops.c:47: > /usr/include/stdbool.h:42:2: #error "Use of is valid > only in a c99 compilation environment." > In file included from ../../gdb/gdb/valops.c:47: > ../../gdb/gdb/m3-lang.h:34: error: syntax error before > "processing_pm3_compilation" > ../../gdb/gdb/m3-lang.h:34: warning: type defaults to `int' in > declaration of `processing_pm3_compilation' > ../../gdb/gdb/m3-lang.h:34: warning: data definition has no type or > storage class > ../../gdb/gdb/m3-lang.h:43: error: syntax error before > "procedures_have_extra_block" > ../../gdb/gdb/m3-lang.h:43: warning: type defaults to `int' in > declaration of `procedures_have_extra_block' > ../../gdb/gdb/m3-lang.h:43: warning: data definition has no type or > storage class > gmake[2]: *** [valops.o] Error 1 > gmake[2]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu/gdb' > gmake[1]: *** [all-gdb] Error 2 > gmake[1]: Leaving directory `/opt/cm3/cm3/m3-sys/m3gdb/SOLgnu' > gmake: *** [all] Error 2 From hosking at cs.purdue.edu Tue Aug 21 16:00:31 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:00:31 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <58211.194.138.127.36.1187679467.squirrel@mail.elegosoft.com> Message-ID: <6A045050-347B-4C7D-A185-1E1B240F940F@cs.purdue.edu> I'm the old one: SunOS arthur.cs.purdue.edu 5.8 Generic_117350-47 sun4u sparc SUNW,Sun- Fire-V250 On Aug 21, 2007, at 9:34 AM, Alex Bochannek wrote: > "Olaf Wagner" writes: > >> Without haveing investigated any of the issues above -- all this >> sounds to me like you are using a quite old Solaris system. I'd like >> to see the exact versions you and Tony use to build the software >> (uname -a). At least it might be a different worth to docuement. > > Not really. It's a V480 with Solaris 10: > > Kernel version: SunOS 5.10 Generic_118833-17 > > Alex. From hosking at cs.purdue.edu Tue Aug 21 16:52:18 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 21 Aug 2007 10:52:18 -0400 Subject: [M3devel] Couple of CM3 build comments (Solaris/SPARC). In-Reply-To: References: <42374.194.138.127.36.1186733484.squirrel@mail.elegosoft.com> <20070816174655.GD15579@jack.stsp.lan> <887D1E82-F659-43F2-8A58-B1196A441864@cs.purdue.edu> <2FE82772-CE8E-4E49-898A-A10175FD70B7@cs.purdue.edu> Message-ID: <5F334086-0745-4C8D-9351-48C3B618271A@cs.purdue.edu> Yes, those are because your m3cc backend is configured to us GNU as, so it is just a matter of making sure your cm3.cfg uses the same assembler. In general, these problems are difficult to reconcile. I suspect we want SOLgnu to assume a full GNU toolchain and SOLsun to assume no GNU toolchain, but in many instances systems are configured as some hybrid of the two. For example, my gcc installation on Solaris is configured to use /usr/ccs/bin/as, and I don't have GNU ld installed either -- hence the definitions in my cm3.cfg. On Aug 21, 2007, at 10:21 AM, Alex Bochannek wrote: > Tony Hosking writes: > >>> o Ran into another problem with as and for some reason Tony's >>> cm3.cfg >>> used /usr/ccs/bin/as, which chokes on the GNU as directives. >>> Changed >>> cm3.cfg again. >> >> Which file chokes? Is it because your m3cc is configured to use >> GNU as? > > I get these kinds of errors: > > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: unknown opcode > ".subsection" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1558: error: statement syntax > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: unknown opcode > ".previous" > /usr/ccs/bin/as: "RTHeapMap.ms", line 1619: error: statement syntax > > for RTHeapMap, RTTipe, RTTypeMap, RTExStack, and Poly when I run > do-cm3-core buildship. > >>> o do-cm3-core.sh completed and I did an install-cm3-compiler.sh >>> upgrade, >>> again as root since it's writing it into /usr/local/cm3 >>> >>> o Finally, did a do-cm3-std.sh buildship, which ran for quite a >>> while. >>> >>> o Ran into compile problems with Gdb (looked like a C99 issue, but I >>> didn't investigate it further. Just ran a cm3 in m3gdb again >>> and the >>> error is below.) >>> >>> o Commented out m3gdb in def-std-pkgs.sh and did a do-cm3-std.sh >>> buildship again. >>> >>> o The compile and install succeeded and I now have a nice new >>> cm3-d5.5.0. >>> >>> o Compiler some stuff in m3-games, just to make sure it really works >>> and >>> it looks like I am OK for now. I do see a number of core dumps >>> though >>> with some of apps, but I am not going to debug that at this point. >> >> What's core dumping? Is this from before my fixes to thread stopping >> yesterday? > > I just ran into problems with a couple of things out of m3-demo and > m3-games. Don't recall what it was (although Juno won't run right > now), > but I will do a CVS update and build a new system and report back if > something doesn't work. > > Alex. From dragisha at m3w.org Wed Aug 22 11:44:55 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:44:55 +0200 Subject: [M3devel] crashes everywhere Message-ID: <1187775896.31487.97.camel@faramir.m3w.org> *** *** runtime error: *** An array subscript was out of range. *** file "../src/runtime/common/RTCollector.m3", line 2316 *** m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: (m3gdb) bt #0 0x00d54402 in ?? () #1 0x430c7ba0 in raise () from /lib/libc.so.6 #2 0x430c94b1 in abort () from /lib/libc.so.6 #3 0x00eaf2ff in Crash () at RTOS.m3:20 #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 #7 0x00e9f212 in Crash (a= ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion `compiler_kind != ck_pm3' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From dragisha at m3w.org Wed Aug 22 11:58:44 2007 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 22 Aug 2007 11:58:44 +0200 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <1187776724.31487.103.camel@faramir.m3w.org> Another program, similar code... bt before I do set lang (still no idea why' problem there): #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol table. ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in symbol table. ) at RTCollector.m3:2316 #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol table. ) at Panda.m3:353 Line 353 is: AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); > INC(d.pdf.nextFontNumber); (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); *) AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not declared it "UNTRACED REF", and it is ref to C structure... I see these RTCollector bugs are happening from time to time, so I am posting this because I hope it can help other people identify it before they hit list (as I did:). m3gdb nastyness remains... On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- Dragi?a Duri? From rodney.bates at wichita.edu Wed Aug 22 16:27:07 2007 From: rodney.bates at wichita.edu (Rodney M. Bates) Date: Wed, 22 Aug 2007 09:27:07 -0500 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <46CC47BB.1050502@wichita.edu> I was unable to reproduce this m3gdb problem, but I looked at ways this could happen. In your case, m3gdb is getting conflicting information about whether it is debugging a program compiled by pm3 or cm3. As a workaround, since we know (don't we?) that it is actually cm3, and that agrees with what m3gdb thinks at the time of the assertion failure, it is probably safe in this case to ignore the message and proceed. You might even try the bt command again immediately. This error should self-heal at this point. It would be helpful to me if you sent me the output of these commands: objdump -G | grep MM__m3main objdump -G | grep ObjectTypecell Substitute the appropriate paths for your linked executable and wherever it finds libm3core. Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. -- ------------------------------------------------------------- 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 Wed Aug 22 17:31:08 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:31:08 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187775896.31487.97.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> Message-ID: <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> I can't speak for m3gdb, but something seems seriously wrong with your installation. What program is causing this crash? Please also tell me the version number of ThreadPThread.m3. The most recent version is 1.48 of 2007-08-20. On Aug 22, 2007, at 5:44 AM, Dragi?a Duri? wrote: > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/runtime/common/RTCollector.m3", line 2316 > *** > > m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: > > (m3gdb) bt > #0 0x00d54402 in ?? () > #1 0x430c7ba0 in raise () from /lib/libc.so.6 > #2 0x430c94b1 in abort () from /lib/libc.so.6 > #3 0x00eaf2ff in Crash () at RTOS.m3:20 > #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 > #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 > #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, msgA=16_00ed8ee8, > msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 > #7 0x00e9f212 in Crash (a= > ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion > `compiler_kind != ck_pm3' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:47:14 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:47:14 -0400 Subject: [M3devel] crashes everywhere (only m3gdb remains unsolved) In-Reply-To: <1187776724.31487.103.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <1187776724.31487.103.camel@faramir.m3w.org> Message-ID: On Aug 22, 2007, at 5:58 AM, Dragi?a Duri? wrote: > Another program, similar code... bt before I do set lang (still no > idea > why' problem there): > > #15 0x00d126f2 in _m3_fault (arg=Invalid C/C++ type code 39 in symbol > table. > ) from /usr/local/cm3/pkg/m3core/LINUXLIBC6/libm3core.so.5 > #16 0x00d0ef32 in CheckStoreTraced (ref=Invalid C/C++ type code 41 in > symbol table. > ) at RTCollector.m3:2316 > #17 0x0016bb96 in CreateFont (d=Invalid C/C++ type code 26 in symbol > table. > ) at Panda.m3:353 > > Line 353 is: > > AddDictItem(d, fo.obj, panda.TextValue, "Type", "Font"); > AddDictItem(d, fo.obj, panda.TextValue, "Subtype", "TrueType"); > fontident := "F" & Fmt.Pad(Fmt.Int(d.pdf.nextFontNumber), 8, '0'); >> INC(d.pdf.nextFontNumber); > (* AddDictItem(d, fo.obj, panda.TextValue, "Name", fontident); > *) > AddDictItem(d, fo.obj, panda.TextValue, "BaseFont", fo.f.name()); > > d is traced, d.pdf is NOT, ie NOT really... a bug was, I've not > declared > it "UNTRACED REF", and it is ref to C structure... What is the type of d, d.pdf, and d.pdf.nextFontNumber? Are you saying d.pdf is REF? Yet you are storing an UNTRACED REF in it? The garbage collector will definitely become confused in that situation. Try using gdb instead of m3gdb so I can see the value of the parameter 'ref' passed to CheckStoreTraced from CreateFont. > > I see these RTCollector bugs are happening from time to time, so I am > posting this because I hope it can help other people identify it > before > they hit list (as I did:). > > m3gdb nastyness remains... > > On Wed, 2007-08-22 at 11:44 +0200, Dragi?a Duri? wrote: >> *** >> *** runtime error: >> *** An array subscript was out of range. >> *** file "../src/runtime/common/RTCollector.m3", line 2316 >> *** >> >> m3gdb, on setting lang to Modula-3 (capital M) ant bt, gives this: >> >> (m3gdb) bt >> #0 0x00d54402 in ?? () >> #1 0x430c7ba0 in raise () from /lib/libc.so.6 >> #2 0x430c94b1 in abort () from /lib/libc.so.6 >> #3 0x00eaf2ff in Crash () at RTOS.m3:20 >> #4 0x00ea1624 in Crash (msg=NIL) at RTProcess.m3:65 >> #5 0x00e9ed85 in EndError (crash=TRUE) at RTError.m3:115 >> #6 0x00e9ea3a in MsgS (file=16_00ed7368, line=2316, >> msgA=16_00ed8ee8, >> msgB=16_00ed3530, msgC=16_00ed8ee8) at RTError.m3:40 >> #7 0x00e9f212 in Crash (a= >> ../../gdb/gdb/m3-util.c:1057: internal-error: note_is_cm3: Assertion >> `compiler_kind != ck_pm3' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. >> >> I am using cvshead cm3, as of few days ago. > -- > Dragi?a Duri? From hosking at cs.purdue.edu Wed Aug 22 17:51:28 2007 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 22 Aug 2007 11:51:28 -0400 Subject: [M3devel] crashes everywhere In-Reply-To: <1187797188.31487.113.camel@faramir.m3w.org> References: <1187775896.31487.97.camel@faramir.m3w.org> <4F4DC3D2-02DB-4526-B038-EDC5A54AAA38@cs.purdue.edu> <1187797188.31487.113.camel@faramir.m3w.org> Message-ID: <86C11DDE-5087-414B-9256-B7727041B020@cs.purdue.edu> On Aug 22, 2007, at 11:39 AM, Dragi?a Duri? wrote: > It is not... It was a bug I've explained in my replly to message you > replied to...