Date: 1 Mar 90 13:53:47 PST From: RHOOVER@IBM.COM (Roger Hoover) Subject: SRC Modula-3 on SPARC I'm trying to build Modula-3 on a Sun SPARCstation 1, using the SPARC-1.2alpha.tar.Z file from gatekeeper.dec.com: HOST = SPARC TARGET = SPARC The make fails when it tries to use the nonexistant compiler/m3compiler.host for pass 0 while building Thread.i3 as shown below: ------ thread starting on Wed Feb 28 13:36:48 EST 1990 .ROOT/driver/m3 -Y4.ROOT/loader/m3ld -Y5.ROOT/loader/m3ld2 -Y0.ROOT/compiler/m3compiler.host -C Thread.i3 .ROOT/driver/m3: Cannot execute .ROOT/compiler/m3compiler.host (No such file or directory) .ROOT/driver/m3: .ROOT/compiler/m3compiler.host exited, status=1 *** Error code 1 It is not clear to me where the make is supposed to build this file. Is it possible to bootstrap the compiler on a SPARCstation? What am I doing wrong? roger hoover rhoover@ibm.com ------------------------------------------------------------------------------ Date: 7 Mar 90 17:12:00 PST From: Subject: SRC Modula-3 version 1.4 SRC Modula-3 ------------ A new release, version 1.4, of the SRC Modula-3 compiler and runtime are available now. This is the second public release of SRC Modula-3. The system was developed at the DEC Systems Research Center. It is being distributed in source form (mostly Modula-3) and is available for public ftp. You must have a C compiler to build and install the system. The primary changes since version 1.2 are: - many bugs are fixed - interfaces to the X libraries were added - the export restrictions are removed from the license - the system was ported to a SPARCstation - debugging is simpler SRC Modula-3 is available without signing any license agreements. If you chose to sign the commercial license, you will be able to use SRC Modula-3 commercially. Modula-3 is a new language. The goals of its design are best encapsulated in the preface to the Modula-3 Report [1]: The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the garbage collector and the very lowest levels of the thread implementation, the entire system is written in Modula-3. The system is known to run on VAX's and DECstation 3100's running Ultrix 3.1 and on SPARCstations running SunOS 4.0.3. The system is available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The SRC Modula-3 files are in '/pub/DEC/Modula-3'. Those files include: m3-1.4.tar.Z - the system Report{1,2,3}.ps - the revised language report Release-1.4.ps - the user manual (PostScript) The compressed tar files are about 4.5Mbytes after compression. The entire system requires about 45Mbytes of disk space to build and install. We are maintaining a mailing list of those interesting in SRC Modula-3. The list is 'm3@src.dec.com'. To be added to the list send a message to 'm3-request@src.dec.com'. We may also be reached at: Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 Enjoy, Bill Kalsow and Eric Muller References ---------- [1] The Modula-3 Report (Revised), L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89. DEC, VAX, DECstation and Ultrix are trademarks of Digital Equipment Corporation. PostScript is a trademark of Adobe Systems Incorporated. SPARCstation and SunOS are probably trademarks of Sun Microsystems Inc. ------------------------------------------------------------------------------ Date: 8 Mar 90 04:56:55 PST From: reid@ctc.contel.com (Tom Reid x4505) Subject: Add to list Please add me to the SRC Modula-3 mailing list (if I am not already on it). Thanks, Tom. Thomas F. Reid, Ph. D. (703)818-4505 (work) Contel Technology Center (703)742-8720 (home) 15000 Conference Center Drive Net: reid@ctc.contel.com P.O. Box 10814 Chantilly, Va. 22021-3808 ------------------------------------------------------------------------------ Date: 8 Mar 90 15:47:44 PST From: tony@uhura.Colorado.EDU (Tony Sloane) Subject: Availability on MC68020 I notice that the compiler doesn't have a supported MC68020 version. Has anyone done the work necessary to run it on such a machine? In particular, I'm interested in Sun machines running SunOS 3 or 4. Tony --------------------------------------------------------------------------- Tony Sloane Computer Science Department tony@boulder.colorado.edu University of Colorado at Boulder ------------------------------------------------------------------------------ Date: 9 Mar 90 14:49:50 PST From: davidh@ic.Berkeley.EDU (David S. Harrison) Subject: Problem with calling supertype methods I recently built and installed m3 version 1.4 on a DECstation 3100 running field test Ultrix 4.0. I think I have found a problem (or a misunderstanding) with object inheritance in the compiler. The revised report shipped with the distribution states on p. 13: "If T is an object type and m is the name of one of T's methods, then T.m denotes T's default m method. This notation makes it convenient for a subtype method to invoke a corresponding method of one of its supertypes." I wrote the program below to try out this feature. The Modula front end does not complain but the C compiler produces the following warning: ccom: Warning: oops.m3, line 22: struct/union or struct/union pointer required (((t6_methods*)((t6_TC->defaultMethods) + (0+(sizeof (t17_methods)) )))->_print) (); } } return; }; -------------------------------------------^ The resulting program suffers a segmentation fault. Below is the modula source: ---- cut here --- MODULE Main; IMPORT Text, Wr, Stdio, Fmt; TYPE Basic = OBJECT METHODS print() END; TYPE Point = Basic OBJECT x, y: INTEGER METHODS print := PrintPoint END; TYPE LabelPoint = Point OBJECT lbl: Text.T METHODS print := PrintLabel END; PROCEDURE PrintPoint(self: Point) = BEGIN Wr.PutText(Stdio.stdout, "[x="); Wr.PutText(Stdio.stdout, Fmt.Int(self.x)); Wr.PutText(Stdio.stdout, ",y="); Wr.PutText(Stdio.stdout, Fmt.Int(self.y)); Wr.PutText(Stdio.stdout, "]") END PrintPoint; PROCEDURE PrintLabel(self: LabelPoint) = BEGIN Wr.PutText(Stdio.stdout, "lbl = {"); Wr.PutText(Stdio.stdout, self.lbl); Wr.PutText(Stdio.stdout, "} point = "); Point.print(); END PrintLabel; VAR p: Point; l: LabelPoint; BEGIN p := NEW(Point, x := 12, y := 10); l := NEW(LabelPoint, x := -3, y := 4, lbl := "foo"); p.print(); Wr.PutText(Stdio.stdout, "\n"); l.print(); Wr.PutText(Stdio.stdout, "\n"); END Main. --- cut here --- Now its my understanding that the quoted paragraph allows the call to the supertype print routine in PrintLabel. Is this a bug or have I missed something? David Harrison UC Berkeley Electronics Research Lab (davidh@ic.Berkeley.EDU, ...!ucbvax!ucbcad!davidh) ------------------------------------------------------------------------------ Date: 9 Mar 90 15:31:30 PST From: moss%ibis@cs.umass.edu (Eliot Moss) Subject: Problem with calling supertype methods Undoubtedly other will comment, too, but don't you think it will work a little better if you tell the poor routine what Point you want printed? E.g.: Point.print (self); Remember that p.print () should result in invoking pp (self) where pp is a dynamically obtained procedure. Here, you are doing a static call. I would also agree that the Modula-3 compiler should have given you a nasty error message here. As for the C code produced, I am not surprised that it blew up, though it does appear to be a reasonable rendition of what you wrote. In short, you're both wrong! (It's neither a dessert topping nor a floor wax!) Eliot ------------------------------------------------------------------------------ Date: 12 Mar 90 04:59:32 PST From: neil%minster.york.ac.uk@NSFnet-Relay.AC.UK Subject: distribution HELP!! cant ftp the m3 distribution - can someone out there send me the report, and sources etc on a sun readable tape?? - we cant ftp form here!! Neil Audsley ------------------------------------------------------------------------------ Date: 12 Mar 90 13:47:02 PST From: neil%minster.york.ac.uk@NSFnet-Relay.AC.UK Subject: m3 distribution HELP!! cant ftp the m3 distribution - can someone out there send me the report, and sources etc on a sun readable tape?? - we cant ftp form here!! Neil Audsley ------------------------------------------------------------------------------ Date: 13 Mar 90 00:59:04 PST From: levy@brouilly.inria.fr (Jean-Jacques Le'vy) Subject: M3 Distribution too... You can find it at INRIA Rocquencourt in following file: /home/beaune/para/Modula-3/m3-1.4.tar.Z You can call me at 39-63-56-89 if problem. -JJ- ------------------------------------------------------------------------------ Date: 13 Mar 90 03:17:57 PST From: ETIP050@FRCIRP81.BITNET Subject: M3 Distribution too... We can't ftp neither from here. Could any body send me the files kept in directory '/pub/DEC/Modula-3' at ftp 'gatekeeper.dec.com' on tape ? (SUN, Xenix, or 1/2"). Thanks Pascal Bourguignon Universite Pierre et Marie Curie - Paris 6 ------------------------------------------------------------------------------ Date: 13 Mar 90 09:11:46 PST From: ETIP050@FRCIRP81.BITNET Subject: M3 Distribution... We can't ftp neither from here. Could any body send me the files kept in directory '/pub/DEC/Modula-3' at ftp 'gatekeeper.dec.com' on tape ? (SUN, Xenix, or 1/2"). Thanks Pascal Bourguignon Universite Pierre et Marie Curie - Paris 6 ------------------------------------------------------------------------------ Date: 13 Mar 90 10:45:04 PST From: george@cis.ohio-state.edu (George M. Jones) Subject: M3 Distribution too... From: ETIP050%FRCIRP81.BITNET@cunyvm.cuny.edu Date: 13 MAR 90 03:17:57 We can't ftp neither from here. Could any body send me the files kept in directory '/pub/DEC/Modula-3' at ftp 'gatekeeper.dec.com' on tape ? (SUN, Xenix, or 1/2"). Thanks Pascal Bourguignon Universite Pierre et Marie Curie - Paris 6 The Modula-3 1.4 distribution is now available from osu-cis via anonymous UUCP. The following is an extract from the periodicly published GNU.how-to-get file. ----------------------------------------------------------------------------- This file (osu-cis!~/GNU.how-to-get) describes how to get the following software from osu-cis via semi-anonymous UUCP: C++ Test Suite Compress ET++ GNU Binary Utilities GNU Assembler GNU Awk GNU Bash GNU Bison GNU C++ Compiler GNU C++ Library GNU C Compiler GNU Chess GNU DBM GNU Debugger GNU Diff GNU Emacs GNU Emacs Ada support GNU Emacs Franz interface GNU Emacs Lisp Manual GNU File Utils GNU Go GNU Gperf & Cperf GNU Grep GNU Indent GNU Lex GNU Make GNU Pins & Art GNU Plot & Plot2PS GNU Sed GNU Tar GNUS Ghostscript Gnews Ispell JOVE KA9Q Kermit Leif m3 MIT C Scheme Mg2a NNTP News Oops PCRRN Patch Pathalias Protoize Proxy ARP RCS RFCs & IDEAS RN SB Prolog STDWIN Sendmail Smail Tcsh VM There's a lot of other available miscellany that isn't explicitly listed here. You can find out about it in the file osu-cis!~/ls-lR.Z The Computer and Information Science Department of the Ohio State University provides Free Software Foundation GNU products (and others) via UUCP only as a redistribution service. Anything found here is only and exactly as it would be found on the indicated Internet hosts, were one to acquire it via anonymous FTP (like we did); or else saved it as it flowed past on the Usenet source distribution newsgroups. OSU CIS takes no responsibility for the contents of any of the distributions described in this message. See the Distribution document (emacs/etc/DISTRIB when you unpack and build Emacs) and the GNU Emacs General Public License (emacs/etc/COPYING, similarly). Much of the GNU software is in beta-test. For a list of the current statuses (stati?), ask gnu@prep.ai.mit.edu for a copy of the latest FSF order form. How to reach osu-cis via uucp =============================== Here is a set of L.sys or Systems file lines suitable for osu-cis: # # Direct Trailblazer # osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon # # Direct V.32 (MNP 4) # osu-cis Any ACU 9600 1-614-292-1153 in:--in:--in: Uanon # # Micom port selector, at 1200, 2400, or 9600 bps. # Replace ##'s below with 12, 24, or 96 (both speed and phone number). # NOTE: 9600 bps Micom access may not yet be operational, or may be flaky. # osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r \d\r in:--in:--in: Uanon Modify as appropriate for your site, of course, to deal with your local telephone system. There are no limitations concerning the hours of the day you may call. We are deeply grateful to Philips Components of Eindhoven, the Netherlands for the donation of a Trailblazer Plus and a Codex 2264 for use by the community at large. Where the files are =================== Most items exist on osu-cis for distribution purposes in compressed tar form, exactly what you find on the indicated hosts in the specified origin files. Most items are cut into pieces for the sake of uucp sanity. This separation helps if your uucp session fails midway through a conversation; you need restart only with the part that failed, rather than the whole beast. The pieces are typically named with a root word, followed by letter pairs like "aa" and "bj," meaning that the pieces are all named with the root word, followed by a dash and the suffixes indicated, using the letters inclusive between the two limits. All pieces but the last are 100,000 bytes long, and the fragmentary last piece has some smaller size. The instruction listings below are alphabetized as in the summary block above. . . . m3 - DEC/Olivetti Modula 3 Compiler -- Source is gatkeeper.dec.com Root is ~/m3 Files are readme.txt, size is 3824 bytes M3Report1.ps.Z, size is 46725 bytes M3Report2.ps.Z, size is 48956 bytes M3Report3.ps.Z, size is 49685 bytes Release-1.4.ps.Z, size is 80989 bytes Report.ps.Z, size is 109935 bytes m3-1.4.tar.Z.part-00, size is 100000 . . . m3-1.4.tar.Z.part-42, size is 100000 m3-1.4.tar.Z.part-43, size is 52835 readme.txt is the message that was posted by DEC announcing the 1.4 release. It describes briefly what Modula 3 is and the particular files are. ------------------------------------------------------------------------------ Date: 14 Mar 90 06:34:22 PST From: dwa%desargues@ucsd.edu (Don Anderson) Subject: Sparc 1.4 compilation woes One of our systems people got the job of trying to install the Sparc version of the 1.4 release of the Modula-3 compiler on our new Solbourne. He has encountered some specific problems. We have not yet managed a successful installation of the Sparc version. Are there folks out there who have advice for us? Feel free to correspond directly with Mr. Parent (bparent@ucsd.edu) as routing things through me is likely to get them garbled. "Too many cooks" syndrome and all that.. ----------------------------< cut here >--------------------------------- From bparent@sdcc3.UCSD.EDU Tue Mar 13 17:39:20 1990 From: bparent@sdcc3.UCSD.EDU (Brian Parent) To: dwa@sdcc3.UCSD.EDU Subject: Modula3 make trouble Could you confirm (via the mailing list??) that my guess is correct? There seems to be a typo in the file ./compiler/exprs/ExprParse.mc based on the output from make when its trying to compile that file. Line 686 of the file as distributed reads: -------| v &VS_RealExpr__NewS__c219e06a01e90d6b, &VS_IntegerExpr__New__864172512ee81acd , &VS_ConcatExpr__New__ab8b85833d72c085, &VS_NotExpr__New__ec8622143bd956b4, and I believe it should read: -------| v &VS_RealExpr__NewS__c219e06a31e90d6b, &VS_IntegerExpr__New__864172512ee81acd , &VS_ConcatExpr__New__ab8b85833d72c085, &VS_NotExpr__New__ec8622143bd956b4, After making the change, and running make, it completed successfully. Furthermore, the first example in the documentation runs as expected. However, that's certainly not proof of correctness. To follow my line of reasoning, read on (its long, > 60 lines): Here's the relevant output from make: ------ exprs starting on Tue Mar 13 11:56:17 PST 1990 [lots of stuff deleted] .ROOT/driver/m3 -Y3.ROOT/loader/m3ld -Y4.ROOT/loader/m3ld2 -g -D -D.:../misc:.. / types:../builtinTypes:../values:../exprs:../builtinOps:../stmts:../word:../SPAR C :.ROOT/runtime/interfaces:.ROOT/lib/interfaces -X1I.ROOT/runtime/kernel -c Expr P arse.mc "ExprParse.m3", line 286: warning: undeclared initializer name VS_RealExpr__New S __c219e06a01e90d6b "ExprParse.m3", line 286: warning: illegal pointer combination [more stuff deleted] ------ exprs done on Tue Mar 13 12:00:00 PST 1990 then later on (still building from within the "compiler" directory) ------ SPARC done on Tue Mar 13 12:06:17 PST 1990 (cd o.TARGET; ld -r -X -o .compiler.o ../?*/o.TARGET/.*.o) .ROOT/driver/m3 -Y3.ROOT/loader/m3ld -Y4.ROOT/loader/m3ld2 -o m3compiler.target o.TARGET/.compiler.o \ -L .ROOT/runtime/m3run.target.o .ROOT/lib/m3lib.target.a ld: Undefined symbol _VS_RealExpr__NewS__c219e06a01e90d6b --- compiler done on Tue Mar 13 12:06:57 PST 1990 when I run "nm .compiler.o | grep VS_RealExpr__NewS" I get: U _VS_RealExpr__NewS__c219e06a01e90d6b 000f2e30 D _VS_RealExpr__NewS__c219e06a31e90d6b Checking the file ./compiler/exprs/ExprParse.mc, I found where the undefined reference is and changed the the '0' to a '3'. Here's the diffs: *** ExprParse.mc.orig Wed Mar 7 14:40:34 1990 --- ExprParse.mc Tue Mar 13 16:38:46 1990 *************** *** 683,689 **** &VS_NamedExpr__Split__034b990827a61ddc, &VS_RangeExpr__New__994c470a3fe972 e a, &VS_ConsExpr__New__3a31cb372bfb3a81, &VS_CallExpr__New__eef778f52be44442, &VS_CallExpr__MethodList__7e87c2d720444b71, &VS_TypeExpr__New__1f10d03a284 8 7bf7, &VS_SubscriptExpr__New__233fed2b234c5b11, &VS_QualifyExpr__New__e5b2c7be3fb31b56, &VS_DerefExpr__New__344f21aa225a20 1 e, &VS_TextExpr__New__59f81ed53141605d, &VS_LongrealExpr__NewS__b15c4da130a8ffb 1 , ! &VS_RealExpr__NewS__c219e06a01e90d6b, &VS_IntegerExpr__New__864172512ee81a c d, &VS_ConcatExpr__New__ab8b85833d72c085, &VS_NotExpr__New__ec8622143bd956b4, &VS_NegateExpr__New__62e617003229e476, &VS_PlusExpr__New__bf642fd93973a3b9 , &VS_InExpr__New__54d7e56a3756b0b5, &VS_SubtractExpr__New__557c96a3390757a2, &VS_AddExpr__New__a866024b2bf44084, &VS_ModExpr__New__1adaaaa62850acc7, &V S _DivideExpr__New__91c519523520f59a, &VS_DivExpr__New__ae8d1054208575fc, &VS_MultiplyExpr__New__85eb063a2ffd28fc, &VS_CompareExpr__NewLT__d3bc668c3 3 8ffbca, &VS_CompareExpr__NewLE__270970fc3aa3e654, --- 683,689 ---- &VS_NamedExpr__Split__034b990827a61ddc, &VS_RangeExpr__New__994c470a3fe972 e a, &VS_ConsExpr__New__3a31cb372bfb3a81, &VS_CallExpr__New__eef778f52be44442, &VS_CallExpr__MethodList__7e87c2d720444b71, &VS_TypeExpr__New__1f10d03a284 8 7bf7, &VS_SubscriptExpr__New__233fed2b234c5b11, &VS_QualifyExpr__New__e5b2c7be3fb31b56, &VS_DerefExpr__New__344f21aa225a20 1 e, &VS_TextExpr__New__59f81ed53141605d, &VS_LongrealExpr__NewS__b15c4da130a8ffb 1 , ! &VS_RealExpr__NewS__c219e06a31e90d6bd, &VS_ConcatExpr__New__ab8b85833d72c0 85, &VS_NotExpr__New__ec8622143bd956b4, &VS_NegateExpr__New__62e617003229e476, &VS_PlusExpr__New__bf642fd93973a3b9 , &VS_InExpr__New__54d7e56a3756b0b5, &VS_SubtractExpr__New__557c96a3390757a2, &VS_AddExpr__New__a866024b2bf44084, &VS_ModExpr__New__1adaaaa62850acc7, &V S _DivideExpr__New__91c519523520f59a, &VS_DivExpr__New__ae8d1054208575fc, &VS_MultiplyExpr__New__85eb063a2ffd28fc, &VS_CompareExpr__NewLT__d3bc668c3 3 8ffbca, &VS_CompareExpr__NewLE__270970fc3aa3e654, The End. ------------------------------------------------------------------------------ Date: 14 Mar 90 08:26:50 PST From: bparent@UCSD.EDU (Brian Parent) Subject: add me Please add me to the mailing list. email address: bparent@ucsd.edu Thanks. ------------------------------------------------------------------------------ Date: 14 Mar 90 11:27:06 PST From: muller@jumbo.dec.com Subject: Re: Sparc 1.4 compilation woes You are right, the version stamp for RealExpr.NewS is : VS_RealExpr__NewS__c219e06a31e90d6b I have checked the distribution and it seems to be right. I suspect some transmission/uncompress problem. For what it is worth, running sum(1) on m3-1.4.tar (uncompressed version) yields: 14057 14900 Eric Muller. ------------------------------------------------------------------------------ Date: 14 Mar 90 16:59:46 PST From: glassman@jumbo.dec.com (Lucille Glassman) Subject: Modula-3 on Apollo workstations Most of the Apollo port now works. There are some significant differences between Domain/OS and Ultrix, the most notable of which is that Apollo's Domain/OS does not support ITIMER_PROF. Any suggestions on how to handle Threads? The differences between Domain/OS and Ultrix are mostly contained in the file currently called "runtime/os/Ultrix.i3". It seems silly (IMHO) to keep the name "Ultrix" for a module that is specific to Domain/OS. On the other hand, there are a lot of "IMPORT Ultrix" statements, and I don't think they should be changed for each new target system. For now, I'm leaving "Ultrix" in place, but there must be a better solution... ------------------------------------------------------------------------------ Date: 14 Mar 90 16:59:46 PST From: glassman@jumbo.dec.com (Lucille Glassman) Subject: Modula-3 on Apollo workstations Most of the Apollo port now works. There are some significant differences between Domain/OS and Ultrix, the most notable of which is that Apollo's Domain/OS does not support ITIMER_PROF. Any suggestions on how to handle Threads? The differences between Domain/OS and Ultrix are mostly contained in the file currently called "runtime/os/Ultrix.i3". It seems silly (IMHO) to keep the name "Ultrix" for a module that is specific to Domain/OS. On the other hand, there are a lot of "IMPORT Ultrix" statements, and I don't think they should be changed for each new target system. For now, I'm leaving "Ultrix" in place, but there must be a better solution... ------------------------------------------------------------------------------ Date: 15 Mar 90 13:53:24 PST From: glassman@jumbo.dec.com (Lucille Glassman) Subject: bug in ArrayExpr.GenLiteral: omits curly braces M3 compiles an array into a C struct containing an array. (See Compiler in compiler/types/ArrayType.m3.) Array values are written with only one set of curly braces, which can cause problems with some C compilers. In particular, the Apollo C compiler refused to compile lib/fingerprint/PolyBasis.ic, which contains arrays of arrays. The solution I came up with is to emit nested curly braces for array values; this happens in GenLiteral in compiler/exprs/ArrayExpr.m3: *** compiler/exprs/ArrayExpr.m3~ Wed Mar 7 14:40:10 1990 --- compiler/exprs/ArrayExpr.m3 Wed Mar 14 16:46:30 1990 *************** *** 210,216 **** WHILE (last > 0) AND Expr.IsZeroes (p.args[last]) DO DEC (last) END; IF (NUMBER (p.args^) > 0) THEN ! Emit.Op ("{\001\n"); j := 0; k := MAX (1, 5 * Target.INTSIZE DIV Type.Size (element)); (* elts/line* ) FOR i := 0 TO last DO --- 210,216 ---- WHILE (last > 0) AND Expr.IsZeroes (p.args[last]) DO DEC (last) END; IF (NUMBER (p.args^) > 0) THEN ! Emit.Op ("{ {\001\n"); j := 0; k := MAX (1, 5 * Target.INTSIZE DIV Type.Size (element)); (* elts/line* ) FOR i := 0 TO last DO *************** *** 227,233 **** END; END; IF (j # 0) THEN Emit.Op ("\n") END; ! Emit.Op ("\002}"); ELSE (* empty array *) (* generate nothing... *) END; --- 227,233 ---- END; END; IF (j # 0) THEN Emit.Op ("\n") END; ! Emit.Op ("\002} }"); ELSE (* empty array *) (* generate nothing... *) END; ------------------------------------------------------------------------------ Date: 15 Mar 90 15:54:05 PST From: glassman@jumbo.dec.com (Lucille Glassman) Subject: changes to m3ld.sh for portability M3ld is set up such that any argument ending with ".o" or ".a" is considered a file. On an Apollo, there are some options that should not be treated as files, but still end with ".o" (e.g., -Ainlib,m3runtime.o). A minor change to m3ld.sh fixes this: *** loader/m3ld.sh~ Wed Mar 7 14:35:26 1990 --- loader/m3ld.sh Thu Mar 15 14:41:36 1990 *************** *** 52,57 **** --- 52,63 ---- case -p: set preserve = 1 breaksw + case -l*: + set files = (${files} $1) + breaksw + case -*: + set options = (${options} $1) + breaksw case *.mo: case *.io: set tempname = /tmp/m3ld_$$_`basename $1`.o *************** *** 62,73 **** case *.o: case *.a: set files = (${files} $1) - breaksw - case -l*: - set files = (${files} $1) - breaksw - case -*: - set options = (${options} $1) breaksw case *: set files = (${files} $1) --- 68,73 ---- ------------------------------------------------------------------------------ Date: 15 Mar 90 17:58:00 PST From: Subject: Muddled headers The last several messages to the SRC Modula 3 mailing list have arrived here at SRC with garbled headers. In particular, they all claim to be from me, although they're actually apparently from ogicse!mntgfx!lisch. I believe this is a local problem, and I've asked our mail/news gurus to have a look at it. Meanwhile, sorry for any confusion. (I don't know what's happening outside of SRC -- presumably it all looks fine.) --Lucille ------------------------------------------------------------------------------ Date: 17 Mar 90 20:16:09 PST From: dean@saturn.Berkeley.EDU (R. Drew Dean) Subject: M-3 1.4 & SPARC threads... Has anyone yet gotten the test program p007 to run properly on a SPARC ? The compiler installation went smoothly, but it appears that multiple threads don't quite work properly for the SPARC, there appears to be a stack overflow. Also, does anyone have a proper Imakefile for the tests directory ? (Sorry I haven't hacked X so I'm not very familiar with imake). Thanks, Drew Dean dean@xcssun.Berkeley.EDU ------------------------------------------------------------------------------ Date: 20 Mar 90 05:49:01 PST From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Availability on MC68020 On 8-Mar-90 Tony Sloane writes: > I notice that the compiler doesn't have a supported MC68020 version. > Has anyone done the work necessary to run it on such a machine? In > particular, I'm interested in Sun machines running SunOS 3 or 4. > I have been porting m3 version 1.4 to the HP9000/300 series using HP/UX. This is a 68040 (or 30?) box. It has run most of the p series tests. There are a few things to be done, however. Most notably to rewrite the operating system interface. HP/UX is SYSV-ish with POSIX and X/OPEN stuff and a few own things. I have updated a number of the Ultrix things to get the compiler and the test programs working, but there are more things to be done. It is just a matter of translating the .h files to Modula-3. Someone mentioned the differences on Apollo and suggsted to get rid of the Ultrix names. I would like to ask the SRC team to come with some reosonable naming scheme for differentiating the various Unix flavours. I.e some files should be named Unix*, with the specific implementations in Ultrix*, HPUX* etc. I have a few questions/problems. When I run test p012 as a.out < /dev/null, I get a Rd__Failure exception. The problem is that /dev/null is a character special device, and thus is treated as a terminal, but it does not allow FIONREAD ioctls. So the code in UltrixFilestream.TerminalReaderSeek should allow for the error ENOTTY on the ioctl. When I run the test from a terminal as stdin, it will not stop on end-of-file. I understand that FIONREAD returns 0 on end-of -file, and then does no read(), so it is unable to detect the eof. After the eof it continues reading. I don't understand how this can work on Ultrix. Maybe someone can enlighten me. It is impossible to debug this situation because of the timer interrupts. And then, is there a simple make/imake command to run all testprograms? Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: 20 Mar 90 12:06:57 PST From: muller@jumbo.dec.com Subject: Re: Availability on MC68020 > There are a few things to be done, however. Most notably to rewrite the > operating system interface. HP/UX is SYSV-ish with POSIX and X/OPEN stuff > and a few own things. I have updated a number of the Ultrix things to get > the compiler and the test programs working, but there are more things to be > done. It is just a matter of translating the .h files to Modula-3. It is just a matter of doing it, but what a pain to do. I am getting more and more of section 2 done; hopefully, it will be complete for the next release. > Someone mentioned the differences on Apollo and suggsted to get rid of the > Ultrix names. I would like to ask the SRC team to come with some reosonable > naming scheme for differentiating the various Unix flavours. I.e some files > should be named Unix*, with the specific i> mplementations in Ultrix*, HPUX* > etc. Here is how I intend to handle this problem. Standard application programs (those that want to be portable, that is) should use interfaces such as readers and writers. These are OS independant. At the other end, we have interfaces that are merely translations in Modula-3 syntax of the system include files. For the next release, the core library has an ultrix3.1 subdir, with interfaces Ultrix.i3, Usignal.i3, Usem.i3 and so on. (Some of them have implementations for the macros.) We can create many such subdirs and have the Imakefile depend on the system being built to take the right one. In between, things like UltrixFileStream that connect readers and writers to open, read, write and so on. These are OS specific and will also be chosen based on the system being built. I don't think that an attempt to define a generic u*x OS will work. And that would not help for VMS. However, there is a definition for part of it: the ANSI-C standard libraries. The corelib contains a C subdir that gives these interfaces in Modula-3 syntax. In the systems we support, we will make sure that these interfaces are implemented (regardless of the availability of an ANSI-C library). Of course, all this is very tentative are suggestions are more than welcome. Also, we will need the help of other people, as we don't have access to most of the u*x variants. > When I run test p012 as a.out < /dev/null, I get a Rd__Failure exception. > The problem is that /dev/null is a character special device, and thus is > treated as a terminal, but it does not allow FIONREAD ioctls. So the code > in UltrixFilestream.TerminalReaderSeek should allow for the error ENOTTY on > the ioctl. > When I run the test from a terminal as stdin, it will not stop on > end-of-file. I understand that FIONREAD returns 0 on end-of -file, and then > does no read(), so it is unable to detect the eof. After the eof it > continues reading. I don't understand how this can work on Ultrix. Maybe > someone can enlighten me. I am also confused right now. I'll look at that more closely. > It is impossible to debug this situation because of the timer interrupts. Yes, debugging multi-threaded programs is a pain. Ideas ? > And then, is there a simple make/imake command to run all testprograms? It seems that the organization of the tests is confusing everybody. Sorry about that. From the test directory, "make test" should build and run all the tests (the objects depend on the compiler, so they are rebuilt iff the compiler did not change; and the output file of a test depends on the executable, so the test is not rerun if it wasn't recompiled). ------------------------------------------------------------------------------ Date: 20 Mar 90 15:49:40 PST From: goldberg@parc.xerox.com (David Goldberg) Subject: Is this program valid? The SRC compiler accepts the program below as valid, but if my reading of the manual is correct, apply does not cover SendSig (because of the raises clauses), and so the program has a static error. -david MODULE Main; IMPORT Thread; PROCEDURE SendSig(self: Thread.Closure): REFANY = BEGIN END SendSig; PROCEDURE Alarm(): Thread.T = BEGIN RETURN(Thread.Fork(NEW (Thread.Closure, apply := SendSig))); END Alarm; BEGIN VAR t: Thread.T; BEGIN t := Alarm(); EVAL(Thread.Join(t)); END; END Main. ------------------------------------------------------------------------------ Date: 20 Mar 90 16:16:58 PST From: goldberg@parc.xerox.com (David Goldberg) Subject: Re: Availability on MC68020 Re: From the test directory, "make test" should build and run all the tests What you meant to say was "imake/m3make test", there is no makefile in the tests directory. -david ------------------------------------------------------------------------------ Date: 21 Mar 90 03:14:35 PST From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: Availability on MC68020 On 20-Mar-90 David Goldberg writes: > Re: > > From the test directory, "make test" should build > and run all the tests > > What you meant to say was "imake/m3make test", there is no makefile > in the tests directory. > This does not work. When looking at the Imakefile in the root directory, I noticed that ther is a 'source_subdir (tests)'. Should this not be a 'subdir (tests)'? Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: 24 Mar 90 09:19:25 PST From: piet@cs.ruu.nl (Piet van Oostrum) Subject: imake/m3make test I just found out why I can't do m3make test: The Imakefile in the tests directory contains a broken line base test diff cbase ctest cdiff ebase etest ediff \ @@\ pbase ptest pdiff rbase rtest rdiff :: FRC @@\ On my cpp (HP/UX) there is the problem that TABS are not preserved. I have compiled imake with the REDUCED_TO_ASCII_SPACE option but this option depends on a colon being in a rule line. This is not true for the continuation line. Changing this line to: base test diff cbase ctest cdiff ebase etest ediff \ pbase ptest pdiff rbase rtest rdiff :: FRC @@\ solves the problem. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: 25 Mar 90 12:03:18 PST From: piet@cs.ruu.nl (Piet van Oostrum) Subject: SHELL variable Our brain-damaged make on HP/UX uses the SHELL environment variable to determine which shell to use. So I added a line SHELL=/bin/shell to imake/Imake.definitions. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: 26 Mar 90 19:31:11 PST From: Subject: ' in TEXT literals Can somebody from the Modula-3 comittee explain why a ' in a TEXT literal has to be escaped ? Since SRC Modula-3 accepts unescaped ' (and issues a warning), I assume that there is no real need for that escape. Can we get ride of it in the next revision of the report ? puzzled eric. ------------------------------------------------------------------------------ Date: 26 Mar 90 21:48:44 PST From: goldberg@parc.xerox.com (David Goldberg) Subject: semantics of array parameters Shouldn't array parameters be copied if there are not VAR (or READONLY?) That's not what happens with the SRC compiler, as the following program shows: MODULE Main; IMPORT Wr, Stdio, Fmt; CONST maxPoints = 300; VAR pointarr1: ARRAY [0 .. maxPoints - 1] OF INTEGER; PROCEDURE FooVar(VAR pointarr: ARRAY OF INTEGER) = BEGIN FOR i := 0 TO 10 DO pointarr[i] := 2*i; END; END FooVar; PROCEDURE Foo(pointarr: ARRAY OF INTEGER) = BEGIN FOR i := 0 TO 10 DO pointarr[i] := 2*i; END; END Foo; BEGIN FOR i := 0 TO 10 DO pointarr1[i] := i; END; FooVar(pointarr1); Wr.PutText(Stdio.stdout, Fmt.Int(pointarr1[1])); FOR i := 0 TO 10 DO pointarr1[i] := i; END; Foo(pointarr1); Wr.PutText(Stdio.stdout, Fmt.Int(pointarr1[1])); END Main. David Goldberg goldberg@parc.xerox.com ------------------------------------------------------------------------------ Date: 28 Mar 90 13:15:39 PST From: Subject: Re: Is this program valid? > The SRC compiler accepts the program below as valid, but if my reading > of the manual is correct, apply does not cover SendSig (because of the > raises clauses), and so the program has a static error. As you noticed, the program is not valid. The compiler has been fixed. eric. ------------------------------------------------------------------------------ Date: 30 Mar 90 00:50:22 PST From: Subject: Re: semantics of array parameters David Goldberg asks: > Shouldn't array parameters be copied if there are not VAR (or READONLY?) > That's not what happens with the SRC compiler, as the following program > shows: > > [example] Apparently, we lost some piece of code during a rewriting. This used to work in 1.2 and will work again in 1.5. thanks for the report, Eric Muller. ------------------------------------------------------------------------------ Date: Fri, 30 Mar 90 09:52:59 PST From: cohesive!kla!cocos!pat@Sun.COM (Pat Lashley) Subject: Initial impressions I have just pulled the m3 distribution from the osu-cis archives and installed it on my SS1 with little difficulty. My first impression is extremely favorable; but I do have a few comments concerning installation. 1) The use of `MAKE=m3make' breaks with GNU make (3.58); which sets MAKE to the file name with which make was invoked. (This may be a make bug; but I would have to find a copy of the appropriate POSIX spec to be sure.) I'm not sure exactly what functionality is intended, but perhaps it could be achieved by replacing MAKE with MAKEPROG and adding `MAKEPROG = MAKE' to Imake.tmpl. 2) The top level Makefile does not provide for the ability to make the programs and libraries separately from the documentation; nor does the installation document mention the I think that you will find that many sites don't have TeX and will be content to use the distributed .ps files. 3) I seem to be missing the legalese directory. This causes the make to fail. It appears to happen after all of the important stuff is done, but is still slightly disconcerting. 4) The tests directory seems to be well set up for comparing outputs after making a change; but isn't very helpfull to verify a first-time installatio n. It would also be very helpfull if the documentation included a table of approximate disk utilization for the various test suites. -Pat ------------------------------------------------------------------------------