Date: 2 Jan 90 09:11:05 PST From: RHOOVER@IBM.COM (Roger Hoover) Subject: Mailing list Please add me to your mailing list: rhoover@ibm.com thanks. ------------------------------------------------------------------------------ Date: 2 Jan 90 10:42:06 PST From: dw@swatter.fly.toronto.edu (Dave Wortman) Subject: Problems with Version 1.2 1. under the Ultrix 2.3 C compiler, compilation of switch.c in thread produces the following errors: ------ thread starting on Fri Dec 29 21:04:06 EST 1989 /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c Thread.i3.c /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c Thread.m3.c /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c ThreadF.i3.c /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c ThreadSupport.i3.c /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c switch.c "switch.c", line 95: warning: illegal pointer combination "switch.c", line 127: warning: illegal pointer combination (cd o.TARGET; ld -r -X -o .thread.o *) ------ thread done on Fri Dec 29 21:05:00 EST 1989 2. some of the shell scripts included in the distribution refer to SRCisms like ~muller and bigtop: that won't work in other environments. Dave Wortman Computer Systems Research Institute University of Toronto ------------------------------------------------------------------------------ Date: 2 Jan 90 10:42:41 PST From: mfeldman@seas.gwu.edu (Mike Feldman) Subject: Welcome > Who are you? I'm a professor of Computer Science at The George Washington University, Washington, DC. Been there 15 years; responsible for the undergrad data structures and compiler courses, the grad compiler and comparative language courses. Teach a seminar in concurrent programming, taught from the perspective of a comparative-languages type. Been an Ada enthusiast for many years (9, I guess now). Wrote data structures books using Ada and Modula-2 as the languages of discourse. I like Ada for its richness in data structures and concurrency and M2 for its cheap compilers. I do NOT like the Wirth blind spots I see in M2: case-sensitivity, lack of ability to pass structured types from functions, other stuff. > What do you plan to do with Modula-3? Well, I'm getting interested in languages that are more object-oriented than Ada. Many of the ideas in C++ are attractive; the awful syntax and the C gotchas are ugly. Eiffel is nice but proprietary. So are the various O-O extensions to Pascal. To the extent that M3 is and stays an open language (i.e. not proprietary), but keeps the admirable de facto standardization that M2 (sort-of) has, I think it could turn out to be a very nice alternative to these languages. If I can get a compiler up and running this semester (starting Jan, 10!) I can use it in my concurrency seminar, as I am using M2 now, as an example of the small-is-beautiful concurrency philosophy. See below. > Are you using SRC Modula-3? Well, I'd like to. I have copied the DEC distribution. We have Sun-3's and an HP-900/835 (SPARC timesharing system). I'd like to find a turnkey implementation for either of these. I sent my license agreement to Olivetti (they have a Sun version) but haven't heard boo from them for at least a month (are you out there, Olivetti???) > Are you porting it to new systems? Only if desperate. Better to glom on to someone more experienced in ports. > What is hard to understand in the documentation? Nothing so far. But I haven't used the language yet. Stay tuned. > Was installation difficult? > What are the bugs in the compiler? > What are the fixes? These three are obviously "too early to say" things. Happy New Year, everyone in M3-land! --------------------------------------------------------------------------- Prof. Michael Feldman Department of Electrical Engineering and Computer Science The George Washington University Washington, DC 20052 +1-202-994-5253 mfeldman@seas.gwu.edu --------------------------------------------------------------------------- ------------------------------------------------------------------------------ Date: 2 Jan 90 11:14:38 PST From: orgass+@rchland.ibm.com (Dick Orgass) Subject: Introduction I'm Dick Orgass at IBM Rochester (Minnesota). I'm very excited about Modula-3 and a small group here in Rochester is exploring the use of Modula-3 because of the significant improvements over Modula-2. I'm interested in using SRC Modula-3 and awaiting completion of the license arrangements. (Our lawyers insisted on making changes to the DEC license.) As soon as the license issue is cleared up, I'm going to start a port to IBM/4.3 (a BSD 4.3 port to the RT) and AIX/PS2. In my opinion, both the original and the revised Modula-3 reports are remarkably clear and concise and I found the report very easy to understand. (I can't comment on the documentation for the compiler yet.) Dick ------------------------------------------------------------------------------ Date: 3 Jan 90 17:38:50 PST From: convex!lieb@uxc.cso.uiuc.edu (Ron Lieberman) Subject: Intro and Problem Introduction: My name is Ron Lieberman and I work for Convex Computer Corporation on our vectorizing/parallelizing Ada compiler. I have been interested in Modula-2 for some number of years and welcome the opportunity to explore the Modula-3 language and compiler. ==================================================== Now for a small problem: The following files appear to be missing from the tests directory: BUGS - a list of known bugs BUGS.* - files used to build BUGS INDEX - a list of the test programs INDEX.* - files used to build INDEX Makefile - builds all test cases Makefile.0 - used to build a single test case Please send along whatever is available. And of course, thanks in advance. Ron ------------------------------------------------------------------------------ Date: 4 Jan 90 08:46:00 PST From: Subject: Re: Problems with Version 1.2 Thanks for the bug reports. > 1. under the Ultrix 2.3 C compiler, compilation of switch.c in thread > produces the following errors: > > /bin/cc -I.ROOT/runtime/kernel -g -DVAX -c switch.c > "switch.c", line 95: warning: illegal pointer combination > "switch.c", line 127: warning: illegal pointer combination To my eyes, switch.c looks fine. Perhaps it's a problem with the Ultrix 2.3 C compiler and void. We're using the Ultrix 3.1 C compiler. With earlier compilers we had to define void=int. > 2. some of the shell scripts included in the distribution refer > to SRCisms like ~muller and bigtop: that won't work > in other environments. The only references to ~muller that I found were in imake/INSTALL-RCS. If you want to use rcs, you'll need to modify those definitions. The distribution that we shipped does not use rcs by default. The only reference to bigtop that I found was in image/m3make.man-7. This file contains internal documentation on the m3make command. That particular reference was explaining our use of rcs. We'll clean up these SRCisms for the next release. - Bill ------------------------------------------------------------------------------ Date: 4 Jan 90 08:59:00 PST From: Subject: Re: Intro and Problem Thanks for pointing out the problem. The tests/README file is out-of-date. Makefile and Makefile.0 have been superseded by the various Imakefiles. The BUGS and INDEX files were generated by the old makefiles, but the new Imakefiles don't create them. We'll remedy the problem for the the next release. - Bill ------------------------------------------------------------------------------ Date: 4 Jan 90 15:50:00 PST From: Subject: ftp access Several people have sent me messages saying that they did not have ftp access, but would like to receive a copy of SRC Modula-3. We are working on a solution... I'll post an update to this message as soon as we have a solution. In the meantime, are there any volunteers for distribution sites on bitnet, usenet, foonet, barnet, ...? - Bill ------------------------------------------------------------------------------ Date: Tue, 9 Jan 90 23:55:19 JST From: Kazuaki Maeda Subject: Questions about m3 1.2 for Sparc Station I Hello, everyone. Can I install Modula-3 Compiler on Sparc Station I (SunOS 4.0.3) ? I want to use Modula-3 Compiler on our Sparc Station I. So I got SPARC-1.2alpha.tar.Z from gatekeeper.dec.com. But I could not compile runtime/SPARC/stack.c. Error messages are bellow: "stack.c", line 116: JB_SP undefined "stack.c", line 233: JB_SP undefined I don't know how to modify stack.c. What shall I do for this case ? Thank in advance, Kaz ---------------------------------------- Kazuaki Maeda Department of Administration Engineering Keio University, JAPAN E-mail : kaz@ae.keio.ac.jp ---------------------------------------- ------------------------------------------------------------------------------ Date: 10 Jan 90 13:32:54 PST From: goldberg@parc.xerox.com (David Goldberg) Subject: syntax accepted by the SRC compiler The SRC compiler accepts the statement TRY Wr.PutText (Stdio.stdout, "\n"); Wr.Close (Stdio.stdout); EXCEPT Wr.Failure, Wr.Error => ; END; which the language definition appears to say is invalid, because what follows the => must be a statement, and ; is not a statement. The ORC compiler does reject this as syntactically incorrect. David Goldberg ------------------------------------------------------------------------------ Date: 11 Jan 90 04:44:01 PST From: metz@iam.unibe.ch (Igor Metz) Subject: m3 on sun-4? I'm new to this list, so forgive me if this question has already shown up before. Has anybody already tried to port src m3 to a sun-4? Igor Metz X400: metz@iam.unibe.ch Institut fuer Informatik ARPA: metz%iam.unibe.ch@relay.cs.net und angewandte Mathematik UUCP: ..!uunet!mcsun!iam.unibe.ch!metz Universitaet Bern Phone: (0041) 31 65 49 90 Switzerland Fax: (0041) 31 65 39 65 ------------------------------------------------------------------------------ Date: 11 Jan 90 13:30:11 PST From: norman@a.cs.okstate.edu (Norman Graham) Subject: SRC Modula-3 Installation and Docs Did anyone else have problems installing SRC VAX distribution? I found that 25MB was not enough disk space (but 30-35MB should do it). Next topic: Are there any substantial differences between the Modula-3 User's Manuals found in Release-1.2.ps and doc/doc.ps? I suppect that Release-1.2.ps is more current, although I've not printed doc/doc.ps to do a comparison. All-in-all, the installation went pretty smothly. I look forward to experimenting with the system in the next few weeks. I'm also trying to get some students in our Object-Oriented Programming class to try it out. Cheers, Norm N.B. Is anyone working on a port to Sys V yet? -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, rutgers} 219 Mathematical Sciences Building !okstate!norman Stillwater, OK USA 74078-0599 ------------------------------------------------------------------------------ Date: 11 Jan 90 15:03:26 PST From: zs01+@andrew.cmu.edu (Zalman Stern) Subject: Re: Welcome Who are you? I am a systems programmer at the Information Technology Center (ITC) at Carnegie Mellon University. In the past I have worked on the Andrew Toolkit and various systems type projects here at the ITC (e.g. a dynamic loader). I am currently working on introducing the MACH operating system into the ITC. What do you plan to do with Modula-3? I would like to gain some experience with the language and promote its use here at the ITC. We have done a lot of work with a home grown object oriented preprocessor for C (called class). This has turned out well, but it is still a relatively low functionality language (i.e. lacks garbage collection, exception handling, and strong typing). In addition we would prefer to use a widely accepted language. I am also interested in the development of the "ad hoc standards" that Modula 3 will need to be successful. These include things like conventions for system implementation (e.g. system defined exceptions) to facilitate portability and interfaces/implementations of useful functionality (e.g. a regular expression package). An example of a system implementation concern that affects portability is how a Modula 3 runtime handles running out of memory. Are you using SRC Modula-3? Not seriously at this point. Are you porting it to new systems? I am spending some time on a port to the IBM RT. What is hard to understand in the documentation? Nothing struck me as particularly hard to understand. Of course we should all be doing our best to get more documentation out into the world. Was installation difficult? The only problem I had on the VAX was that . (the current directory) must be in one's path before starting the make. I haven't tried building 1.2 yet. What are the bugs in the compiler? N/A What are the fixes? I'll let you know if I find any. Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 ------------------------------------------------------------------------------ Date: 12 Jan 90 01:05:08 PST From: jv@mh.nl (Johan Vromans) Subject: Re: SRC Modula-3 Installation and Docs [Quoting Norman Graham, on Jan 11 1990, 15:30, in "SRC Modula-3 Install"] | Did anyone else have problems installing SRC VAX distribution? I found | that 25MB was not enough disk space (but 30-35MB should do it). No, no problems after I obtained sufficient disk space. I currently have 46000 blocks in use in the m3 tree (after generation). I also needed > 1Mb in /tmp . BTW I'm using a VAX3100. Well, my first m3 attempt (the famous hello, world program) set a new world record on program size: c: 8192 pascal: 14336 modula-2: 20480 modula-3: 562176 Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" ------------------------- ------------------------------------------------------------------------------ Date: 12 Jan 90 01:14:12 PST From: paul@trzdor1.ico.olivetti.com (Paul Hudson) Subject: m3 on sun-4? Well, I ported it to a Sun-3 with almost no problems (and without a Vax of any sort ...) BUT I then had to delete the whole lot. If you read the copyright, you will find you cannot export it without licenses from the US government. Anyone going to comment on this? Makes a mockery of the claim that src can be used without signing license agreements, as the original announcement claimed. As just an individual, getting an export license is a ludicrous amount of work. Paul. paul@trzdor1.ico.olivetti.com, ..!mcvax!i2unix!iconet!trzdor1!paul PS. Given where I work, I could always use the Olivetti version, but the main point still applies. ------------------------------------------------------------------------------ Date: 12 Jan 90 08:57:09 PST From: rpp386!aubrey@cs.utexas.edu Subject: Initial benchmark --- A Modula-2 Diskette format program In article 17537@rpp386.Cactus.ORG I released a self contained Modula-2 program to format a floppy diskette on an XT. There has been interest in translating it to C, and I have interest in getting some benchmark on what effort there is to work in Modula-3. Would someone volunteer to look at the program, and run it through the SRC M3 compiler. The original was posted to comp.lang.modula2, comp.os.minix. There may be interest also in posting the output to the mailing list. Please send e-mail to me if you are interested in watching what goes on, and I'll either echo to you are post a 'petition' to the list to make it public. If the article is missing, I will email it also. j---Thanks. ------------------------------------------------------------------------------ Date: 12 Jan 90 08:58:48 PST From: schweize@hplabsb.hpl.hp.com (Philippe S. Schweizer) Subject: Modula-2 on personal computers Hi Does anybody have a port of Modula-3 to IBM PC or Apple Macintosh ? Is somebody working on that ? (I stupidly sell my VAX 11/725 some months ago) Regards Philippe Schweizer (415) 857 7847 ------------------------------------------------------------------------------ Date: 12 Jan 90 11:21:00 PST From: Subject: Re: syntax accepted by the SRC compiler David is right. The SRC compiler has a bug/feature that accepts empty statements. We'll fix the problem in the next release. To fix the problem in your own copy: change compiler/stmts/Stmt.m3 from: PROCEDURE Parse (...) = BEGIN ... REPEAT WHILE (cur.token = TK.tSEMI) DO GetToken () END; ... UNTIL (cur.token # TK.tSEMI); RETURN first END Parse; to: PROCEDURE Parse (...) = BEGIN ... LOOP ... IF (cur.token # TK.tSEMI) THEN RETURN first END; GetToken (); (* ; *) END; END Parse; - Bill ------------------------------------------------------------------------------ Date: 12 Jan 90 11:25:00 PST From: Subject: Re: SRC Modula-3 Installation and Docs Release-1.2.ps and doc/doc.ps should be identical. We made Release-1.2.ps so that interested people could read the manual without grabbing the entire system. Sorry for any confusion we may have caused. - Bill ------------------------------------------------------------------------------ Date: 12 Jan 90 13:09:00 PST From: Subject: Re: SRC Modula-3 Installation and Docs Johan Vromans pointed out that "hello world" in Modula-3 required more space than in C, Pascal or Modula-2. I repeated his test. Here's a little more data: linked program: file size text data bss total file/total C: 8192 4096 1024 0 5120 1.6 Pascal: 14336 8192 2048 444 10684 1.3 Modula-2: 25600 11264 3072 0 14336 1.8 Modula-3: 562176 72704 11264 1616 85584 6.6 main.o: file size text data bss total file/total C: 142 20 16 0 36 3.9 Pascal: 443 92 16 0 108 4.1 Modula-2: 4143 116 16 0 132 31.4 Modula-3: 1100 176 36 0 212 5.2 Some observations: SRC Modula-3 generates many more symbol table bytes relative to text+data bytes than the other compilers. We're using extra symbols with long, funny names to enforce cross compilation consistency between modules. (I don't know why the Modula-2 .o file was so large.) Included in Modula-3's 85K of runtime library was support for garbage collection, object types, threads, exceptions and extensible I/O streams. Larger programs will probably exhibit different results. - Bill ------------------------------------------------------------------------------ Date: 12 Jan 90 13:23:00 PST From: Subject: Export restrictions Ouch. We're trying to improve the export situation. We cannot make the system freely copyable and then make it our responsibility to see that everyone who grabs a copy is permitted to by the US government. I would guess (and I'm not a DEC lawyer) that there is nothing in SRC Modula-3 that is restricted. We're checking. We want to strike the export clause from the copyright so that we can distribute the system via comp.sources. Then, all of you who've asked for copies but don't have ftp access will have another chance. - Bill P.S. As of yesterday at least 230 copies of SRC Modula-3 have been ftp'ed. ------------------------------------------------------------------------------ Date: 12 Jan 90 13:43:00 PST From: Subject: typecode bug Miron Livny reported that anonymous instances of REF REAL don't get the same typecode in separately compiled modules. The problem is in the runtime code that assigns typecodes. To fix the problem edit runtime/kernel/M3Runtime.c (lines 540, 541) from: finish_phase_1_type_registration () ... /* Then we identify the types that have the same fingerprints and brands * / for (it0 ... for (it1 ... if ((t0->typecode ... ... (strcmp (t0-brand, t1->brand) == 0) && (strlen (t0->brand) != 0)) { .... to: finish_phase_1_type_registration () ... /* Then we identify the types that have the same fingerprints and brands * / for (it0 ... for (it1 ... if ((t0->typecode ... ... (t0->brand != NIL) && (t1->brand != NIL) && (strcmp (t0-brand, t1->brand) == 0)) { .... - Bill ------------------------------------------------------------------------------ Date: 12 Jan 90 15:25:00 PST From: Subject: the report is available in small chunks The "Modula-3 Report (revised)" is now available in smaller chuncks from gatekeeper.dec.com, in /pub/DEC/Modula-3/M3Report{1,2,3}.ps. Please, let us know if you have problems. Eric. ------------------------------------------------------------------------------ Date: 13 Jan 90 08:13:59 PST From: kaz@ae.keio.ac.jp (Kazuaki Maeda) Subject: Re: m3 on sun-4? Hello, everyone. |>Date: Fri, 12 Jan 90 10:14:12 +0100 |>From: paul@trzdor1.ico.olivetti.com (Paul Hudson) |> |> |>Well, I ported it to a Sun-3 with almost no problems (and without a |>Vax of any sort ...) |> |>BUT |> |>I then had to delete the whole lot. If you read the copyright, you |>will find you cannot export it without licenses from the US |>government. Really ? .....Oh.....I found it. The copyright says that I cannot export without licenses form the US government. So unfortunately, I deleted all files of Modula-3 compiler. Can I get the licence ? How can I get it ? I am thankful to Paul for his advice. Kaz. ---------------------------------------- Kazuaki Maeda Department of Administration Engineering Keio University, JAPAN E-mail : kaz@ae.keio.ac.jp ---------------------------------------- ------------------------------------------------------------------------------ Date: 13 Jan 90 09:27:23 PST From: george@cis.ohio-state.edu (George M. Jones) Subject: ftp access From: kalsow@src.dec.com (Bill Kalsow) Date: 4 Jan 1990 1550-PST (Thursday) Reply-To: m3@src.dec.com In the meantime, are there any volunteers for distribution sites on bitnet, usenet, foonet, barnet, ...? The following two files are now available on for anonymous uucp from osu-cis (and anonymous ftp from tut.cis.ohio-state.edu) in ~/m3 -rw-r--r-- 1 george 2813917 Jan 1 10:14 DS3100-1.2.tar.Z -rw-r--r-- 1 george 103558 Jan 13 12:20 M3Report1.ps -rw-r--r-- 1 george 109352 Jan 13 12:20 M3Report2.ps -rw-r--r-- 1 george 105183 Jan 13 12:20 M3Report3.ps -rw-r--r-- 1 george 239528 Jan 12 14:57 Release-1.2.ps -rw-r--r-- 1 george 258305 Jan 13 12:19 Report.ps -rw-r--r-- 1 george 2820426 Jan 12 15:30 VAX-1.2.tar.Z Instructions listing phone numbers etc. for how to get things from osu-cis are posted periodicly to comp.sources.d (we are a major redistribution point for GNU). If someone will create a brief README file describing each of the files listed above I will include that in the m3 directory and repost the instructions (Primarily it would be useful to describe the difference between Report.ps and M3Report#.ps). BTW, I would have replied sooner, but I was having some problems with my personal mail/news reading interface (news/mail all rolled into one inside GNUS). ---George Jones ------------------------------------------------------------------------------ Date: 13 Jan 90 09:55:50 PST From: george@cis.ohio-state.edu (George M. Jones) Subject: m3 on sun-4? Date: Fri, 12 Jan 90 10:14:12 +0100 From: paul@trzdor1.ico.olivetti.com (Paul Hudson) Well, I ported it to a Sun-3 with almost no problems (and without a Vax of any sort ...) I have not had/made to the time to look into building m3 yet (*sigh*). Are you saying that you were able to take the distributed sources, without a workingversion (Vax, DecStation) to bootstrap with and produce a working version on the Sun 3 (SunOS ?). I susepcted that that might be possible since the intermediate C files all seem to have been supplied, but again, I have not gotten as far as typing "make" to see what happens. I would be quite interested in a Sun-3 version, could you send my your diffs ? ---George Jones OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325 george@cis.ohio-state.edu or ...!osu-cis!george If it requires paper, it is the wrong interface. ------------------------------------------------------------------------------ Date: 15 Jan 90 14:43:56 PST From: moss%takahe@cs.umass.edu (Eliot Moss) Subject: TRY statement syntax non-problem This is with regard to David Goldberg's difficulty with this construct: TRY ... EXCEPT Wr.Failure, Wr.Error => ; END; The latest version of the Report has the production: Handler = ExceptionID { "," ExceptionID } [ "(" Ident ")" ] "=>" Stmts. Note: that is Stmts, *not* Stmt. Here is the Stmts production: Stmts = [ Stmt { ";" Stmt } [ ";" ] ] It is clear that Stmts can produce ";", so the original construct is legal and should be accepted. The SRC compiler appears to be correct and the ORC compiler incorrect, on this point. This syntax has not changed through the various versions of the Report, so I assume it is an unintended (and probably easily fixed) oversight on the part of the ORC compiler team. Just to add an opinion, I think the Report has this right, since Modula 2 and Modula 3 both put Stmts where one would have Stmt in Pascal. The Modula approach avoids adding extra begin/end pairs when you have more than one statement (at the cost of requiring a terminator for if/then/else, loops, etc.). We did the same thing in CLU, between the 0.x version and the 1.0 version, and stuck with the result, finding it much more pleasant. Anyway, cheers all! Eliot ------------------------------------------------------------------------------ Date: 15 Jan 90 23:58:00 PST From: Subject: Re: ftp access > If someone will create a brief README > file describing each of the files listed above I will include that > in the m3 directory and repost the instructions (Primarily it would be > useful to describe the difference between Report.ps and M3Report#.ps). Here is an attempt (that should make its way to gatekeeper:/pub/DEC/Modula-3/README at some point): ---------------------------------------------------------------------------- This directory contains recent versions of SRC Modula-3, the implementation of the Modula-3 language by the System Research Center, a research laboratory of Digital Equipment Corporation. The Modula-3 language is described in the "Modula-3 Report (revised)", available as a technical report from: System Research Center Digital Equipment Corporation 130 Lytton Av Palo Alto, CA 94301 USA This report is present in PostScript format in this directory, either in one piece as Report.ps, or in three pieces are M3Report{1,2,3}.ps. The SRC implementation of Modula-3 is distributed in the form of a compressed tar file, one for each kind of architecture for which SRC Modula-3 is available: VAX VAX running Ultrix 3.1 DS3100 DECstation running Ultrix 3.1 The files are named -.tar.Z. Each file contains all the sources of the compiler, runtime and libraries, mostly in Modula-3, for all the available architectures. In addition, each release contains the C files resulting from the compilation of the Modula-3 files for the corresponding architecture. Release-.ps is the PostScript version of the release notes. These notes describe the differences with the previous versions, how to install the release and how to use it. They are also available in TeX format within either release, under in doc/doc.tex. You can send mail to m3-request@src.dec.com if you have trouble to access/uncompress/untar these files. Enjoy ! ---------------------------------------------------------------------------- ------------------------------------------------------------------------------ Date: 16 Jan 90 13:43:00 PST From: Subject: Re: TRY statement syntax non-problem Elliot Moss quotes the Stmts production from the revised report: Stmts = [ Stmt { ";" Stmt } [ ";" ] ] and then says that 'It is clear that Stmts can produce ";"'. He must be under the impression that Stmt can produce "", but this is not so. Since Stmt cannot produce "", Stmts cannot produce ";". The Olivetti compiler is correct and the SRC compiler is buggy. ------------------------------------------------------------------------------ Date: 19 Jan 90 02:06:04 PST From: telsys!hueni@hslrswi.uucp (Hermann Hueni) Subject: modula 3 on vax vms ? >Return-Receipt-To: >X-Mailer: ELM [version 2.2 PL0] Hi, Is modula 3 available on a vax vms environment ? regards, hermann -- Hermann Hueni Tel. +41 31 52 92 14 Ascom Autelca Fax. +41 31 52 77 45 CH-3073 Guemligen email: hueni@aut.uucp Switzerland ------------------------------------------------------------------------------ Date: 20 Jan 90 02:41:00 PST From: Subject: Warnings In the release we are working on, we have added warnings for things that look like programming errors: unused variables, incomplete case statements and some others. To make this feature more helpful, here is a little survey: Which situations would like the compiler to detect ? Thanks, Eric Muller. ------------------------------------------------------------------------------ Date: 20 Jan 90 04:43:00 PST From: Subject: Re: Warnings To make this feature more helpful, here is a little survey: Which situations would like the compiler to detect ? Here are some suggestions: 1. Unused variables 2. Unused imported modules 3. Execution paths in a non-void-returning procedure that do not lead to RETURN or RAISE. 4. Unreachable code, e.g. code after an EXIT, RETURN, or RAISE. However, some cases of unreachable code are OK, for example CONST DEBUG = FALSE; IF DEBUG THEN Wr.PuText(stderr, "Ten o'clock and all is well.\n") END; 5. (This is a language wish:) Change the default RAISES clause be RAISES {}, and allow an explicit RAISES ANY to mean the current default. Then optionally flag any operations such as procedure calls and RAISE statements that might raise exceptions not listed in the RAISES clause of the enclosing procedure. (Omitting of course the "standard" exceptions generated by common built-in operations such as NarrowFault, RangeFault, SubscriptFault, AssertFailed, Overflow, Inexact, etc.) 6. Interface items that are not exported by the implementation module. Of course the user must be able to turn these checks off for individual modules, especially checks 5 and 6. I think I would prefer to have these checks controlled by pragmas rather than by compiler switches: among other things, pragmas are more visible, get carried along with the source file, and can be applied to individual modules without messing up the typical Makefile. It would be nice if warnings could be delivered to the user as discreet visual cues (like colored backgrounds, underlining, side bars, etc.) rather then through conventional printed messages. With such a feature the compiler would not have to be overly worried about generating an excessive amount warnings. For example, it would be OK to flag all dead code, even the IF DEBUG example above; or all possible unhandled exceptions, including Overflow, RangeFault, and the like. --jorge ------------------------------------------------------------------------------ Date: 21 Jan 90 09:12:00 PST From: Subject: Rd.GetSub, Wr.PutString Why is one "getSUB" and the other "putSTRING"? I suggest renaming them Rd.GetChars and Wr.PutChars. Also, I noticed that when I use procedures like Rd.GetSub in Modula-2, I almost always want to treat end-of-file as an exceptional condition. Examples of such uses are reading fixed-length records, file and record headers, image scanlines, and similar things. In such applications having Rd.getSub return a character count is inconvenient, since it forces me to explicitly test for end-of-file after every call, and handle the condition on the spot, which only adds to program clutter. The current semantics seems to be geared towards applications that do buffered reads for the sake of efficiency. However, I think this is not something to be encouraged, given that the OS and Rd implementations are already doing such buffering internally, and that the application will usually have to emulate Rd.GetChar in order to process its private buffer. This will be especially true when (if?) Rd.GetChar gets expanded inline. Therefore, I would suggest changing the definition of Rd.GetSub so that it raises EndOfFile instead of returning the character count. I suppose that those few applications that really need the current semantics will be able to simulate it by calling Rd.GetIndex when they get the EndofFile. --jorge ------------------------------------------------------------------------------ Date: 21 Jan 90 13:50:00 PST From: Subject: Spurious warning on INC(address)? The SRC Ultrix Modula-3 compiler seems to generate spurious warning messages for INC(address): srcf3e 10> m3 -g -c Test6.m3 "Test6.m3", line 9: warning: illegal combination of pointer and integer, op > "Test6.m3", line 11: warning: illegal combination of pointer and integer, o p < srcf3e 11> cat Test6.m3 UNSAFE MODULE Test6 EXPORTS Main; PROCEDURE Bar() = VAR string: ARRAY [0..10] OF CHAR; step: INTEGER; adr: UNTRACED REF CHAR; BEGIN adr := ADR(string[0]); INC(adr); step := 1; INC(adr, step); END Bar; BEGIN END Test6. --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 09:23:00 PST From: Subject: Miscellaneous bug reports and discussions The twelve messages that follow are a digest of various discussions and bug reports that I exchanged with the SRC Modula-3 implementors over the past week or so, and that other people in this list may find interesting. If that is not the case, please accept my apologies. All messages refer to the SRC Modula-3 compiler, VAX/Ultrix version, release 1.2. Jorge Stolfi stolfi@src.dec.com, ..!decwrl!stolfi ------------------------------------------------------------------------------ Date: 22 Jan 90 09:23:00 PST From: Subject: Can't write 16_ffffffff ------------------------------------------------------------------ From: stolfi (Jorge Stolfi) I noticed that in Modula-3 I cannot write 16_ff000000 to get Word.T with the first 8 bits set; apparently I must write -16_01000000, or Word.Not(16_00ffffff). --j ------------------------------------------------------------------ From: muller (Eric Muller) That seems right. Remember that Word.i3 says TYPE T = INTEGER; not TYPE T = UNSIGNED; I think Word.Not (16_00ffffff) is better (the compiler will fully evaluate this expression, so no penalty) because it does not rely on the representation of negative integers. [...] eric. ------------------------------------------------------------------ ------------------------------------------------------------------------------ Date: 22 Jan 90 09:24:00 PST From: Subject: Compiler bug in parameter passing ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) I suspect the [SRC Modula-3] compiler is getting the arguments mixed up in the calls to CheckSIGN marked with (***) below, but, strangely, not in the other calls. See the lines marked (* <<<<<<<<< *) in the generated C code. srcf3e 42> m3 -g -c Bug.m3 srcf3e 43> m3 -o Bug Bug.mo srcf3e 44> Bug Testing: f(arg) = SIGN(arg) arg: -5.00000000e-01 val: -1.00000000e+00 ref: -5.00000000e-01 err: -5 .00000000e-01 arg: -2.00000000e+00 val: -1.00000000e+00 ref: -2.00000000e+00 err: 1. 00000000e+00 **** 2 errors *** srcf3e 45> cat Bug.m3 UNSAFE MODULE Bug EXPORTS Main; IMPORT Fmt, Word, OS, Wr, Text; FROM Stdio IMPORT stdin, stderr; VAR errors: INTEGER; PROCEDURE Main() = BEGIN errors := 0; TestSIGN(); IF errors > 0 THEN Wr.PutText(stderr, "\n**** " & Fmt.Int(errors) & " errors ***\n"); OS.Exit(1) END; Wr.PutText(stderr, "\n\nDone.\n"); END Main; PROCEDURE SIGN(x: REAL): [-1 .. +1] = BEGIN IF x > 0.0 THEN RETURN +1 ELSIF x < 0.0 THEN RETURN -1 ELSE RETURN 0 END END SIGN; PROCEDURE TestSIGN() = PROCEDURE CheckSIGN(arg, ref: REAL) = BEGIN Check(arg, FLOAT(SIGN(arg)), ref) END CheckSIGN; BEGIN Wr.PutText(stderr, "\nTesting: f(arg) = SIGN(arg)\n"); CheckSIGN(+1.0, +1.0); CheckSIGN(-1.0, -1.0); CheckSIGN(+0.5, +1.0); CheckSIGN(-0.5, -1.0); (***) CheckSIGN(+2.0, +1.0); CheckSIGN(-2.0, -1.0); (***) CheckSIGN(+0.0, +0.0); END TestSIGN; PROCEDURE Check(arg, val, ref: REAL) = CONST eps = 1.0e-24; VAR err, mag: REAL; BEGIN IF val # ref THEN mag := 1.0; err := FLOAT((LONGFLOAT(val) - LONGFLOAT(ref)) / LONGFLOAT(mag)); Wr.PutText(stderr, " arg: " & Fmt.Pad(Fmt.Real(arg, 8, Fmt.Style.Sci), 14) & " val: " & Fmt.Pad(Fmt.Real(val, 8, Fmt.Style.Sci), 14) ); Wr.PutText(stderr, " ref: " & Fmt.Pad(Fmt.Real(ref, 8, Fmt.Style.Sci), 14) & " err: " & Fmt.Pad(Fmt.Real(err, 8, Fmt.Style.Sci), 14) & "\n" ); INC(errors) END; END Check; BEGIN Main(); END Bug. srcf3e 48> cat Bug.m3.c #line 80 "Bug.m3" #include "M3Runtime.h" [...] #line 56 "Bug.m3" PRIVATE t21 _Bug__TestSIGN (parent) #line 56 "Bug.m3" ADDRESS parent; #line 56 "Bug.m3" { #line 56 "Bug.m3" scope_3 frame; #line 48 "Bug.m3" t1 z8; #line 56 "Bug.m3" CHECKSTACKOVERFLOW; #line 45 "Bug.m3" _Wr__PutText (NIL, _Stdio__stderr, ("\003\000\000\000\042\000\000\000\012 Testing: f(arg) = SIGN(arg)\012" + 4)); #line 47 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, 1.0 , 1.0 ); #line 48 "Bug.m3" z8 = - 1.0 ; #line 48 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, z8, z8); (* <<<<<<<<< *) #line 50 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, 0.5 , 1.0 ); #line 51 "Bug.m3" z8 = - 0.5 ; #line 51 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, z8, z8); (* <<<<<<<<< *) #line 53 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, 2.0 , 1.0 ); #line 54 "Bug.m3" z8 = - 2.0 ; #line 54 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, z8, z8); (* <<<<<<<<< *) #line 56 "Bug.m3" _Bug__TestSIGN__CheckSIGN (&frame, 0.0 , 0.0 ); #line 56 "Bug.m3" return; #line 56 "Bug.m3" }; [...] ------------------------------------------------------------------------------- -- From: muller (Eric Muller) This is really a bug. Somehow, the compiler thinks that z8 hold -1.0, and it needs a variable to put -0.5, so it uses ... z8. We are remodelling the area of variables, so I hope to fix this one on the way. If you don't mind, I would like to include your program in the test suite. thanks, eric. ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) Is this another instance of the "reused temporary" bug? Modula-3: CONST Black = RGB.T{0.0, 0.0, 0.0}; White = RGB.T{1.0, 1.0, 1.0}; Tst ("black", "white", RGB.Black, RGB.White); Generated code: z6.elts[0] = 0.0 ; z6.elts[1] = 0.0 ; z6.elts[2] = 0.0 ; _RGBTest__TestDist__Tst (&frame, ("\003\000\000\000\012\000\000\000black" + 4), ("\003\000\000\000\012\000\000\000white" + 4), z6, z6); --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 09:25:00 PST From: Subject: Compiler bug in temporary variable assignment ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) I believe the lines #line 15 "Bug2.m3" z31 = z19; in the C code below should have been #line 15 "Bug2.m3" _s = z19; --jorge srcf3e 75> cat Bug2.m3 MODULE Bug2 EXPORTS Main; TYPE T = ARRAY [0..5] OF REAL; PROCEDURE RelDist(READONLY x, y: T; eps: REAL := 1.0e-37): REAL = VAR u, v: REAL; s, m: REAL; i: CARDINAL; BEGIN s := 0.0; FOR i := 0 TO 5 DO u := x[i]; v := y[i]; m := MAX(MAX(ABS(u), ABS(v)), eps); s := MAX(ABS(u/m - v/m) - eps/m, s); END; RETURN s END RelDist; BEGIN (* skip *) END Bug2. srcf3e 76> m3 -g -C Bug2.m3 srcf3e 77> cat Bug2.m3.c [...] #line 17 "Bug2.m3" PRIVATE t4 _Bug2__RelDist (parent, _x, _y, _eps) #line 17 "Bug2.m3" ADDRESS parent; #line 17 "Bug2.m3" t5 * _x; #line 17 "Bug2.m3" t5 * _y; #line 17 "Bug2.m3" t4 _eps; #line 17 "Bug2.m3" { #line 17 "Bug2.m3" scope_1 frame; #line 17 "Bug2.m3" t4 __result; #line 17 "Bug2.m3" t9 _i; #line 17 "Bug2.m3" t3 _i_0001; #line 17 "Bug2.m3" t4 _m; #line 17 "Bug2.m3" t4 _s; #line 17 "Bug2.m3" t4 _v; #line 17 "Bug2.m3" t4 _u; #line 13 "Bug2.m3" t9 z7; #line 14 "Bug2.m3" t4 z15; #line 14 "Bug2.m3" t4 z17; #line 14 "Bug2.m3" t4 z18; #line 14 "Bug2.m3" t4 z19; #line 15 "Bug2.m3" t4 z28; #line 15 "Bug2.m3" t4 z29; #line 15 "Bug2.m3" t4 z31; #line 17 "Bug2.m3" CHECKSTACKOVERFLOW; #line 17 "Bug2.m3" (*((int *)(& __result))) = 0; #line 17 "Bug2.m3" (*((int *)(& _i_0001))) = 0; #line 17 "Bug2.m3" (*((int *)(& _m))) = 0; #line 17 "Bug2.m3" (*((int *)(& _s))) = 0; #line 17 "Bug2.m3" (*((int *)(& _v))) = 0; #line 17 "Bug2.m3" (*((int *)(& _u))) = 0; #line 11 "Bug2.m3" _s = 0.0 ; #line 12 "Bug2.m3" { #line 12 "Bug2.m3" register int from; #line 12 "Bug2.m3" register int to; #line 12 "Bug2.m3" register int index; #line 12 "Bug2.m3" from = 0 ; #line 12 "Bug2.m3" to = 5 ; #line 12 "Bug2.m3" for (index = from; index <= to; index += 1) { #line 12 "Bug2.m3" _i = index; #line 13 "Bug2.m3" z7 = _i; #line 13 "Bug2.m3" if ((z7 < 0) || (5 < z7)) RANGEFAULT; #line 13 "Bug2.m3" _u = ((*_x).elts[z7]); #line 13 "Bug2.m3" z7 = _i; #line 13 "Bug2.m3" if ((z7 < 0) || (5 < z7)) RANGEFAULT; #line 13 "Bug2.m3" _v = ((*_y).elts[z7]); #line 14 "Bug2.m3" z15 = _u; #line 14 "Bug2.m3" if (z15 < 0.0) z15 = - z15; #line 14 "Bug2.m3" z17 = _v; #line 14 "Bug2.m3" if (z17 < 0.0) z17 = - z17; #line 14 "Bug2.m3" z18 = z15; #line 14 "Bug2.m3" z19 = z17; #line 14 "Bug2.m3" if (z18 < z19) z18 = z19; #line 14 "Bug2.m3" z15 = z18; #line 14 "Bug2.m3" z17 = _eps; #line 14 "Bug2.m3" if (z15 < z17) z15 = z17; #line 14 "Bug2.m3" _m = z15; #line 15 "Bug2.m3" z15 = _u / _m; #line 15 "Bug2.m3" z17 = _v / _m; #line 15 "Bug2.m3" z18 = z15 - z17; #line 15 "Bug2.m3" z19 = z18; #line 15 "Bug2.m3" if (z19 < 0.0) z19 = - z19; #line 15 "Bug2.m3" z28 = _eps / _m; #line 15 "Bug2.m3" z29 = z19 - z28; #line 15 "Bug2.m3" z19 = z29; #line 15 "Bug2.m3" z31 = _s; #line 15 "Bug2.m3" if (z19 < z31) z19 = z31; #line 15 "Bug2.m3" z31 = z19; #line 15 "Bug2.m3" }; #line 15 "Bug2.m3" }; #line 17 "Bug2.m3" __result = _s; #line 17 "Bug2.m3" return __result; #line 17 "Bug2.m3" }; #line 17 "Bug2.m3" PRIVATE void #line 17 "Bug2.m3" Bug2__initProc () #line 17 "Bug2.m3" { #line 17 "Bug2.m3" scope_2 frame; #line 17 "Bug2.m3" return; #line 17 "Bug2.m3" }; [...] srcf3e 78> ------------------------------------------------------------------------------- -- From: muller (Eric Muller) Yep. Another test program ? eric. ------------------------------------------------------------------------------ Date: 22 Jan 90 09:25:00 PST From: Subject: stderr not closed automatically when directed to a pipe? ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) It seems that stderr is not being closed automatically upon program exit when it has been directed to a pipe. Is this normal, or is it a bug? --jorge ------------------------------------------------------------------------------- -- From: muller (Eric Muller) The language designers did not deem necessary to include module finalization. Hence, if the Stdio package can open stdin, stdout and stderr at program startup, it has no way to close them at program end. You have to call Wr.Close (stdout) and Wr.Close (stderr) explicitly. The difference you observe between terminal and pipe output is due to the different writers that are used: terminal writers are unbuffered, file writers are. Stdio (and FileStream.Openxxx) select the writer brand based on the Ultrix type of the file. I vote against any run-time mechanism by which program could register procedures to be executed at the end of the program as I think this is inferior to the symmetric of what is actually module bodies. eric. ------------------------------------------------------------------------------- -- From: gnelson (Greg Nelson) I took a look at the [Modula-2+ CleanUp interface]. I think it would be worthwhile to translate it into M3 and implement it in the SRC M3 standard runtime. This would fix Jorge's complaint about the automatic closing of Stdio.stdout. Eric argues that this sort of finalization should be provided by a language construct rather than a library interface. I'm afraid that this would provide an illusion of portability rather than the real thing, because the ways in which programs can be stopped or aborted tend to be system-dependent. ------------------------------------------------------------------------------- -- From: muller (Eric Muller) You think that the way Stdio opens the files is not system-dependent ? Suppose that we have finalization bodies in modules; what would be different from Cleanup (except for UnRegister) ? And if finalization is better handled by something like Cleanup, why is initialization better handled by something like bodies ? eric. ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) [Eric:] I vote against any run-time mechanism by which program could register procedures to be executed at the end of the program as I think this is inferior to the symmetric of what is actually module bodies. From a generic programmer's point of view, a nice way to handle this problem would be to have a Close procedure registered to be called when the Wr.T record is garbage-collected (with the assumptions that all data structures are garbage-collected at the end of the program). This would solve not only the problem of users forgetting to close stdout and stderr, but also the similar problem with file writers created inside procedures. (I recall Butler Lampson suggesting such a mechanism, a long time ago; what happened to that?) --jorge ------------------------------------------------------------------------------- -- From: ellis (John R. Ellis) This assumption puts an onerous burden on garbage collectors, requiring them do "precise" GC instead of "approximate" GC (in which most but not all garbage objects get collected). ------------------------------------------------------------------------------- -- From: muller (Eric Muller) I may be difficult to explain to Joe Programmer that "yes, your program is finished and all the useful output is there, but we still need to work another minute to find out that we must close the files." Of course, a minute is (hopefully) exagerated. Furthermore, this would force things like Wr.T to be traced. Seems to me that this is asking a lot. eric. ------------------------------------------------------------------------------- -- From: gnelson (Greg Nelson) > Suppose that we have finalization bodies in modules; what would > be different from [the Modula-2+ Cleanup finalization facility] > (except for UnRegister) ? The EventSet (Stop, Continue, Halt) argument to the procedures seems system-dependent. > if finalization is better handled by something like Cleanup, > why is initialization better handled by something like bodies? A facility for registering initialization procedures couldn't replace module bodies, else what code would register the initialization procedure? I do see that it might be more symmetric to include finalization clauses in module bodies, which are executed after the main module terminates, in the reverse of the order in which the initialization sections were executed. But I'm skeptical of the symmetry, since it seems to rest mostly on the fact that "initialization" rhymes with "finalization". The change would complicate rather than simplify the language spec. And I'm not sure that it would be better in practice than registering finalization procedures. ------------------------------------------------------------------------------ Date: 22 Jan 90 09:28:00 PST From: Subject: Can't declare bit vectors in Modula-3? ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) The Modula-3 compiler grumbles about the declarations marked (**) in the following interface: srcf3e 148> m3 -g -c Bug5.i3 File Bug5.i3, line 14: non-byte aligned packed arrays not supported File Bug5.i3, line 7: non-byte aligned packed arrays not supported 2 errors encountered m3: /proj/ultrix/lib/m3/m3compiler exited, status=2 srcf3e 149> cat Bug5.i3 INTERFACE Bit; TYPE T = BITS 1 FOR [0..1]; PROCEDURE New (value: T): REF T; PROCEDURE NewArray (size: CARDINAL; value: T := 0): REF ARRAY OF T; (**) PROCEDURE UntracedNew (value: T): UNTRACED REF T; PROCEDURE UntracedNewArray ( size: CARDINAL; value: T := 0 ): UNTRACED REF ARRAY OF T; (**) END Bit. srcf3e 150> What is wrong with (traced) REF ARRAY OF Bit.T? Aren't traced objects always byte-aligned? Packed arrays of bits are quite common beasts in systems programming. It would be a pity if they can't be declared in Modula-3, especially considering that they were legal in Modula-2+ (See for example /proj/packages/parseparams/ParseParams.mod). If the problem has to do with SUBARRAY, would it be hard to allow the type ARRAY OF Bit.T (and REFs to same), but require any SUBARRAY of such arrays to have starting index (and length?) divisible by 8? --jorge ------------------------------------------------------------------------------- -- From: kalsow (Bill Kalsow) The SRC Modula-3 compiler does not handle arbitrary packed arrays. It is a choice left to the implementation. Eventually the compiler will "do the right thing". > Packed arrays of bits are quite common beasts in systems programming. > It would be a pity if they can't be declared in Modula-3, especially > considering that they were legal in Modula-2+ (See for example > /proj/packages/parseparams/ParseParams.mod). They are allowed in Modula-3, but this implementation has chosen to restrict their use. (Personal opinion: packed arrays are over-used at SRC. With the exception of low-level drivers that must honor hardware imposed constraints, bit packing should be done by the compiler not the programmer. ParseParams.o is 5K bytes; do you think that packing the parsed flags into bits makes your program any smaller? I've seen very few programs with even 1K parameters.) > If the problem has to do with SUBARRAY, would it be hard to allow > the type ARRAY OF Bit.T (and REFs to same), but require any SUBARRAY > of such arrays to have starting index (and length?) divisible by 8? No. That is probably what will happen when the compiler does handle packed arrays. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 09:29:00 PST From: Subject: Compiler bug in type declarations ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) Compiling the module Bug3.m3 below gives a spurious (?) syntax error. The error goes away if I remove the declaration "TYPE RefArrT = REF ARRAY OF T" from Bug3.i3. --jorge srcf3e 58> m3 -g -c Bug3.i3 srcf3e 60> m3 -g -c Bug3.m3 "Bug3.m3", line 6: TC_Bug3__RefArrT undefined m3: /bin/cc exited, status=1 srcf3e 61> cat Bug3.i3 INTERFACE Bug3; TYPE T = REAL; RefArrT = REF ARRAY OF T; END Bug3. srcf3e 62> cat Bug3.m3 MODULE Bug3; PROCEDURE Foo(): REF ARRAY OF T = VAR s: REF ARRAY OF T; BEGIN s := NEW(REF ARRAY OF T, 10); RETURN s END Foo; BEGIN END Bug3. srcf3e 63> ------------------------------------------------------------------------------- -- From: kalsow (Bill Kalsow) Jorge, thanks for the bug report. Eric, this bug seems to be related to Steve Harrison's indirect type import problem. I think that Type.ExternalDecl should set v.used on any value v that it returns, i.e. Type.ExternalDecl is a funny form of Scope.LookUp. I guess that any caller of Type.ExternalDecl may have to call Value.Declare on the returned value?? - Bill ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------ Date: 22 Jan 90 09:29:00 PST From: Subject: Where should one declare exported VARs? ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) I have an interface called RealExtra.i3 that has two implementations, VAXRealExtra.m3 and MIPSRealExtra.m3. The interface declares the variables First and Last, and the Overflow exception: INTERFACE RealExtra; VAR First: REAL; (* Smallest REAL (-Infinity on IEEE machines) *) Last: REAL; (* Largest REAL (+Infinity on IEEE machines) *) EXCEPTION Overflow; (* Range fault in floating-point operations *) [...] END RealExtra. UNSAFE MODULE VAXRealExtra EXPORTS RealExtra; IMPORT Word; [...] BEGIN First := LOOPHOLE(Word.Not(16_00000000), REAL); Last := LOOPHOLE(Word.Not(16_00008000), REAL); END VAXRealExtra. When I try linking a program that imports RealExtra, the linker complains that those symbols are undefined, even though I explicitly list VAXRealExtra.mo among the objects to be linked with. Indeed, according to "nm", the object code VAXRealExtra.mo does not define those symbols. What should I do? --jorge ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------ Date: 22 Jan 90 09:29:00 PST From: Subject: Modula-3 vs. IEEE floating point ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) In the VAX floating point format (FFLOAT) things are relatively simple: there is only one zero, no infinities, no "Not a Number"s. There is a bit pattern that could conceivably mean "minus zero", but that pattern is officially illegal, is apparently treated as zero, and is not generated by the hardware. In the IEEE floating point format, however, there is a plus zero and threre is a minus zero. The two are different values; for one thing, they print differently: #include main() { double plus_zero, minus_zero plus_zero = 0.0; minus_zero = - plus_zero; fprintf(stderr, "plus_zero = 0x%08x%08x = %21.14le\n", plus_zero, pl us_zero); fprintf(stderr, "minus_zero = 0x%08x%08x = %21.14le\n", minus_zero, m inus_zero); } plus_zero = 0x0000000000000000 = 0.00000000000000e+00 minus_zero = 0x0000000080000000 = -0.00000000000000e+00 There is also a plus infinity and a minus infinity, which are the reciprocals of plus zero and minus zero: double plus_infinity, minus_infinity; plus_infinity = 1.0/plus_zero; minus_infinity = - plus_infinity; fprintf(stderr, "plus_infinity = 0x%08x%08x = %21.14le\n", plus_infinity, plus_infinity); fprintf(stderr, "minus_infinity = 0x%08x%08x = %21.14le\n", minus_infinity, minus_infinity); plus_infinity = 0x000000007ff00000 = Infinity minus_infinity = 0x00000000fff00000 = -Infinity However, plus zero and minus zero seem to be effectively equal in comparisons : fprintf(stderr, "(plus_zero == minus_zero) = %d\n", (plus_zero == minus_zer o)); fprintf(stderr, "(plus_zero > minus_zero) = %d\n", (plus_zero > minus_zero )); (plus_zero == minus_zero) = 1 (plus_zero > minus_zero) = 0 These "features" seem to pose some problems for Modula-3. For one thing, consider the definition of "=". On one hand, +0.0 and -0.0 should not the considered to be the same value, since they behave and print differently. On the other hand, the Modula-3 report (page 45) says that "x = y" should return TRUE if x and y are the same value. So, is "0.0 = -0.0" TRUE or FALSE? For another thing, how do we write "minus infinity" and "plus infinity" in Modula-3? One idea would be have the constant Infinity defined in the Real interface. However, what will the definition look like? The definition CONST Infinity = 1.0/(-0.0) will bomb out on non-IEEE machines. The alternative CONST Infinity = LOOPHOLE(16_, REAL) is ugly, not portable, requires clients to be marked UNSAFE, and won't work for LONGREAL because the "16_" notation can't give more than 31 bits. If the definition read VAR (*CONST*) Infinity: REAL then one could not use Infinity as a default value. The least unsatisfactory solution I can think of allowing FIRST(REAL) and LAST(REAL). This solution would have the advantage of making some sense even in non-IEEE systems. Another problem is that the C compiler has the habit of extending REALs to LONGREALs at the slightest provocation. This probably makes more sense than the paranoid REAL/LONGREAL segregation of Modula-3. [...] Thus, the semantics of REAL in a Modula-3 implementation that generates C code may turn out to be a bit of a mess. ------------------------------------------------------------------------------- -- From: gnelson (Greg Nelson) I don't think that language changes are necessary to support IEEE floating point. An implementation that supports IEEE floating point should include an interface defining Infinity and Nan. Jorge observes that the expressions that define these constants will only work in IEEE implementations; but this is all right, since the interface will only be present in IEEE implementations. The interface can also define an inline procedure with the semantics of the IEEE equality operator. The IEEE standard allows clients to specify whether certain conditions, such as numerical errors, produce exceptions or produce truncated results. In my view, it is up to the Modula-3 implementation whether to provide this facility on a per-thread basis, a per-program basis, or not at all. ------------------------------------------------------------------------------ Date: 22 Jan 90 09:30:00 PST From: Subject: Core dump in M3 gc? ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) [A Modula-3 program of mine dumped core, apparently in the Garbage Collector. REF open arrays are being suspected.] jumbo 3> TabulaTest +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ ./Segmentation fault (core dumped) jumbo 4> dbx TabulaTest dbx version 2.0 of 5/2/89 0:29. Type 'help' for help. reading symbolic information ... [using memory image in core] (dbx) where type_cell(type_code = 378967702), line 393 in "M3Runtime.c" $b55, line 465 in "gc.c" $b54, line 465 in "gc.c" collect(), line 465 in "gc.c" $b57, line 641 in "gc.c" $b56, line 641 in "gc.c" gcalloc(data_size = 2328, code = 1), line 641 in "gc.c" concat(t = ""^A", u = "^F"), line 42 in "strings.c" $b216, line 1344 in "RdMove.m3.c" _Rd__GetLine(parent = (nil), _rd = "D^R^B"), line 1344 in "RdMove.m3.c" _Tabula__Put(parent = (nil), _tab = "", _text = "^L", _just = 1, _row = 0, _col = 0), line 101 in "Tabula.m3" $b4, line 44 in "TabulaTest.m3" _TabulaTest__Main(parent = (nil)), line 44 in "TabulaTest.m3" TabulaTest__initProc(0x1ee10), line 108 in "TabulaTest.m3" init_module(l = 0x1c8bc), line 202 in "M3Runtime.c" UserMain(0x0, 0xa2004), line 187 in "m3ld_2911_c.c" $b116, line 990 in "Thread.m3.c" _Thread__Shell(parent = (nil)), line 990 in "Thread.m3.c" (dbx) ------------------------------------------------------------------------------- -- From: muller (Eric Muller) The bug was in TextRd. If you pick bigtop:/udir/muller/tmp/textrw.o and link with it, that should solve your problem. I also think that the open arrays should not be a problem as the elements do not include REFs. eric. ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) The program now seems to be working fine. Thanks for the prompt fix! --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 09:31:00 PST From: Subject: Compiler dumps core while fingerprinting constant expression ------------------------------------------------------------------------------- -- From: stolfi Bill and Eric, The M3 compiler dumps core while compiling the interface RGB.i3 below. It works OK if I comment out the definition "CONST Undefined = ..." at the end of the interface. I could not reproduce the problem in a smaller file. The core file is /ff/stolfi/m3/m3color/SavedCore. srcf3e 33> make all m3 -D".:../m3realextra:../m3realn" -g -c RGB.i3 runtime error: ASSERT failed CORE DUMPED: m3: /proj/ultrix/lib/m3/m3compiler terminated, signal=10 *** Error code 10 Stop. srcf3e 34> mv core SavedCore INTERFACE RGB; IMPORT Intensity, CIE, HSV, LDW, YPQ, R3; TYPE T = R3.T; [...] CONST Undefined = T{Intensity.Undefined, Intensity.Undefined, Intensity.Undefined}; END RGB. INTERFACE Intensity; TYPE T = REAL; (* A measure of light intensity. *) [...] CONST Undefined: T = 8880888.0; END Intensity. ------------------------------------------------------------------------------- -- From: kalsow (Bill Kalsow) Jorge, thanks for the core dump. Eric, the core dump is caused by fingerprinting the constant expression. QualifyExpr.FPrinter simply calls Expr.FPrint on the rhs, then adds ".name". In this case the rhs is a NamedExpr that is bound to a Module.T. Module.FPrint is an assert FALSE. Either QualifyExpr should FPrint the object its bound to (not the rhs expression), or Module.FPrint should print it's name. - Bill ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------ Date: 22 Jan 90 09:32:00 PST From: Subject: Fingerprinting of REAL literals too sensitive ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) Bill and Eric, When linking a certain program, I keep getting the following errors, m3 -B".:..:../../m3realn:../../m3tabula:../../m3timeextra:../../m3realextra " -o RGBTest RGBTest.mo ../m3color.a m3realn.a m3tabula.a VAXRealExtra.mo m3timeextra.a m3realextra.a /bigtop/udir/muller/tmp/textrw.o -lm Intensity.i3:6: Undefined symbol _VS_Intensity__EqualArr__a05f70a62e95f6c7 referenced from text RGB.i3:6: Undefined symbol _VS_RGB__Dist__3d45911836a8df7e referenced from text RGB.i3:6: Undefined symbol _VS_RGB__Nearest__38d2f7d52407727d referenced fr om text LDW.i3:6: Undefined symbol _VS_LDW__Dist__3d45911836a8df7e referenced from text I trieed recompiling several times the interfaces where those symbols are defined, to no avail. It may be some mistake of mine, but what is strange is that I only get errors in those procedures, even though I import many more items from the same interfaces. One thing that those procedures have incommon is that they all have at least one REAL formal parameter with a default value. Does that ring a bell? If it doesn't, let me know and I will try to generate a small example. --jorge ------------------------------------------------------------------------------- -- From: kalsow (Bill Kalsow) Jorge, I only looked at RGB. The problem appears to be that the real default values have different denotations in RGB.i3 and RGB.m3 [one is 0.00001, the other 1.0e-5]. The work-around is to use the same denotation in each file. (The compiler doesn't convert real literals to binary unless necessary. It decided that the conversion wasn't necessary for version stamps.) Eric, RealExpr.FPrinter and LongrealExpr.FPrinter should convert their values into a cannonical form before fingerprinting them. Sigh. This seems like a tar pit. - Bill ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) Thanks for the tip, I should have noticed the difference. Your suggested work-around solved the problem. ------------------------------------------------------------------------------ Date: 22 Jan 90 09:33:00 PST From: Subject: Spurious "redeclaration" error for local procedure ------------------------------------------------------------------------------- -- From: stolfi (Jorge Stolfi) I can't figure out this error. Is it a compiler bug? srcf3e 105> m3 -g -c Bug4.m3 "Bug4.m3", line 9: redeclaration of _Bug4__Split__DoSplit m3: /bin/cc exited, status=1 srcf3e 106> cat Bug4.m3 MODULE Bug4 EXPORTS Main; IMPORT Rect; PROCEDURE Split () : Rect.T = PROCEDURE DoSplit (): Rect.T = BEGIN RETURN Rect.Empty END DoSplit; BEGIN RETURN Rect.Empty END Split; BEGIN END Bug4. srcf3e 107> ------------------------------------------------------------------------------ Date: 22 Jan 90 10:00:00 PST From: Subject: Re: Warnings The current plan is to support a <*NOWARN*> pragma that disables warnings generated by the line containing the pragma. This pragma is a bit crude since it doesn't distinguish between different types of warning (unused variable, incomplete case, ...) and it doesn't distinguish multiple warnings on a single line. My guess is that in practice <*NOWARN*> will be sufficient. Other opionions? Jorge suggests: > It would be nice if warnings could be delivered to the user as discreet > visual cues (like colored backgrounds, underlining, side bars, etc.) > rather then through conventional printed messages. I like your idea, but for the time being, SRC Modula-3 is a batch compiler that is restricted to printing error messages. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 10:17:00 PST From: Subject: Re: Spurious warning on INC(address)? It's a bug. INC and DEC are trying to do range checking on addresses. The work-around is to use "x := x + a" for INC (x, a) when x is an address. A fix is to edit compiler/builtinOps/{Inc,Dec}.m3. In Inc.m3/Compile at about line 39 after: check := 0; IF (bmin # Target.MININT) ... IF (bmax # Target.MAXINT) ... add IF Type.IsSubtype (Expr.TypeOf (args[0]), Address.T) THEN check := 0 END; Similarly in Dec.m3/Compile at about line 63, make the same addition. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 10:21:00 PST From: Subject: Re: Warnings Bill Kalsow writes: The current plan is to support a <*NOWARN*> pragma that disables warnings generated by the line containing the pragma. Is there going to be a way to disable warnings on an entire block, procedure, or module, other then adding <*NOWARN*> everywhere? Is there going to be a way to disable only warnings of a specific kind (e.g. ignore unused variables, but still complain about unexported interface items?) --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 10:22:00 PST From: Subject: Re: Compiler bug in parameter passing The bug is that the compiler is identifying all real literals within a single expression as common subexpressions. The fix is to edit compiler/exprs/{Real,Longreal}Expr.m3. In the procedure EqCheck at about line 64 replace: | P(b) => RETURN ((a.str = b.str) AND (a.str # NIL)) OR (a.val = b.val); with | P(b) => RETURN ((a.str = b.str) AND (a.str # NIL)) OR ((a.val = b.val) AND (a.val # NOVALUE)); - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 10:27:00 PST From: Subject: Re: Compiler bug in temporary variable assignment The bug is that the compiler is confusing R-values and L-values when it looks for common subexpressions. There isn't a good one-line fix to this problem. It has been fixed in our soon-to-be-released version 2.0. A conservative fix to the problem is to edit compiler/exprs/Temp.m3/LookUp so that it always returns FALSE. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 10:35:00 PST From: Subject: Re: Where should one declare exported VARs? I'd guess that you didn't include the compiled interface RealExtra.io in the arguments passed to the linker. (We don't make them just for fun :-)) Interfaces require some code to initialize variables and register types. Since an interface may be jointly implemented by several modules, there is no easy way to select one of the implementation modules to carry that code. Hence, we compile and produce code for interfaces. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 10:59:00 PST From: Subject: Re: Spurious "redeclaration" error for local procedure Yes. It's a bug. The compiler makes a forward declaration for DoSplit that says it returns a Rect.T. When the compiler finally gets around to compiling the procedure it decides that the return result will be passed out via a by-reference parameter. (This kludgery is necessary with preemptive threads since some C compilers return large results by copying them into global variables.) The fix is to edit compiler/types/ProcType.m3/LargeResult at about line line 255, just before the RETURN statment add: t := Type.Base (t); - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 11:35:00 PST From: Subject: Re: Warnings Jorge asks: > Is there going to be a way to disable warnings on an entire block, > procedure, or module, other then adding <*NOWARN*> everywhere? There will be a compiler flag that disables all warnings in a compilation. Other than that, we haven't planned anything more grandiose. > Is there going to be a way to disable only warnings of a specific > kind (e.g. ignore unused variables, but still complain about unexported > interface items?) We haven't planned to provide such a feature. - Bill ------------------------------------------------------------------------------ Date: 22 Jan 90 13:51:00 PST From: Subject: Core dump from NARROW(v, REF INTEGER)^ m3 crashes with the messages: runtime error: ASSERT failed CORE DUMPED: m3: /proj/ultrix/lib/m3/m3compiler terminated, signal=10 srcff 148> m3 -c T.m3 runtime error: ASSERT failed when fed the program: MODULE T EXPORTS Main; PROCEDURE P (key: INTEGER; value: REFANY): BOOLEAN = BEGIN RETURN NARROW (value, REF INTEGER)^ = key END P; BEGIN END T. Paul ------------------------------------------------------------------------------ Date: 22 Jan 90 15:32:00 PST From: Subject: Re: Where should one declare exported VARs? [Bill Kalsow:] I'd guess that you didn't include the compiled interface RealExtra.io in the arguments passed to the linker. Oops, you're right. I did include the .io file, but it had been compiled for the VAX, and I was trying to link on the DS3100. Blush. --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 15:40:00 PST From: Subject: Spurious "recursive declaration" message? Is this a bug? Is it a new one? srcf3e 5> m3 -g -c Test7.m3 File Test7.m3, line 8: recursive declaration (Bit) 1 error encountered m3: /proj/ultrix/lib/m3/m3compiler exited, status=1 srcf3e 6> cat Test7.m3 MODULE Test7 EXPORTS Main; TYPE Bit = BITS 1 FOR [0..1]; PROCEDURE Foo () = VAR rt: REF ARRAY [0..LAST(Bit)] OF CARDINAL; BEGIN rt := NEW (REF ARRAY [0..LAST(Bit)] OF CARDINAL); END Foo; BEGIN END Test7. --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 20:59:00 PST From: Subject: MIPS C compiler passes "float" as "double"? It seems that the C compiler of the DECstation 3100 passes all procedure arguments of type "float" as "double", no matter how you declare them. This causes LOOPHOLE(realVar, INTEGER) to give the wrong result when realVar is a formal parameter of type REAL. The result apparently is the least significant word of LONGFLOAT(argument). Here is a test program that demosntrates the difference: UNSAFE MODULE Test8 EXPORTS Main; IMPORT Word, Wr, Text, Fmt; FROM Stdio IMPORT stderr; PROCEDURE Foo (arg: REAL) = VAR loc, zero: REAL; BEGIN BinPrint("arg = ", LOOPHOLE(arg, INTEGER)); loc := arg; BinPrint("loc = ", LOOPHOLE(loc, INTEGER)); zero := 0.0; BinPrint("exp = ", LOOPHOLE(loc + zero, INTEGER)); Wr.PutChar(stderr, '\n'); END Foo; PROCEDURE BinPrint(pre: Text.T; x: INTEGER; pos: Text.T := "\n") = BEGIN Wr.PutText(stderr, pre); FOR i := 31 TO 0 BY -1 DO IF Word.Extract(x, i, 1) = 0 THEN Wr.PutChar(stderr, '0') ELSE Wr.PutChar(stderr, '1') END END; Wr.PutText(stderr, pos) END BinPrint; BEGIN Foo(0.0); Foo(1.0); Foo(2.0); Foo(3.1415926); Wr.Close(stderr); END Test8. Output when compiled for a VAX machine (Firefly+Taos): arg = 00000000000000000000000000000000 loc = 00000000000000000000000000000000 exp = 00000000000000000000000000000000 arg = 00000000000000000100000010000000 loc = 00000000000000000100000010000000 exp = 00000000000000000100000010000000 arg = 00000000000000000100000100000000 loc = 00000000000000000100000100000000 exp = 00000000000000000100000100000000 arg = 00001111110110100100000101001001 loc = 00001111110110100100000101001001 exp = 00001111110110100100000101001001 Output when compiled on a DS3100: arg = 00000000000000000000000000000000 loc = 00000000000000000000000000000000 exp = 00000000000000000000000000000000 arg = 00000000000000000000000000000000 <<<<<< loc = 00111111100000000000000000000000 exp = 00111111100000000000000000000000 arg = 00000000000000000000000000000000 <<<<<< loc = 01000000000000000000000000000000 exp = 01000000000000000000000000000000 arg = 01001101000100101101100001001010 <<<<<< loc = 01000000010010010000111111011010 exp = 01000000010010010000111111011010 In fact, from the last example it seems that a real literal argument gets passed with full double precision, without being first truncated/rounded to single. That is, in the call Foo(3.1415) what gets passed is actually 3.1415d0, rather then LONGFLOAT(3.1415e0). I bet a sufficiently perverse programmer will be able to detect the difference inside the procedure Foo, even without using LOOPHOLE. --jorge ------------------------------------------------------------------------------ Date: 22 Jan 90 22:09:00 PST From: Subject: More floating point weirdness Actually, the conflict between the floating-point rules of Modula-3 and C seem to be quite pervasive. The program below gives quite surprising results on both the VAX and the DS3100: MODULE Test9 EXPORTS Main; IMPORT Wr, Text, Fmt; FROM Stdio IMPORT stderr; PROCEDURE Funny (a, b: REAL) = BEGIN IF a = b THEN Wr.PutText(stderr, "EQUAL INSIDE\n") ELSE Wr.PutText(stderr, "DIFFERENT INSIDE\n") END END Funny; VAR tmp: REAL; BEGIN tmp := 0.1; Wr.PutText(stderr, "*** tmp = 0.1 ***\n"); IF tmp = 0.1 THEN Wr.PutText(stderr, "EQUAL OUTSIDE\n") ELSE Wr.PutText(stderr, "DIFFERENT OUTSIDE\n") END; Funny(tmp, 0.1); Wr.Close(stderr); END Test9. srcf3e 34> m3 -g -o Test9 Test9.m3 srcf3e 35> Test9 *** tmp = 0.1 *** DIFFERENT OUTSIDE DIFFERENT INSIDE Hre is the generated C code: typedef float t1; PRIVATE t1 _Test9__tmp; PRIVATE t21 _Test9__Funny (parent, _a, _b) ADDRESS parent; t1 _a; t1 _b; { scope_1 frame; t5 z2; CHECKSTACKOVERFLOW; z2 = (_a == _b); if (z2) { _Wr__PutText ([...]EQUAL INSIDE[...]); goto if_1_end; }; _Wr__PutText ([...]DIFFERENT INSIDE[...]); if_1_end: /**/; return; }; PRIVATE void Test9__initProc () { [...] _Test9__tmp = 0.1 ; _Wr__PutText ([...]); z7 = (_Test9__tmp == 0.1 ); if (z7) { _Wr__PutText ([...]EQUAL OUTSIDE[...]); goto if_2_end; }; _Wr__PutText ([...]DIFFERENT OUTSIDE[...]); if_2_end: /**/; _Test9__Funny (NIL, _Test9__tmp, 0.1 ); _Wr__Close (NIL, _Stdio__stderr); return; }; Here is the (VAX) assembly code: __Test9__Funny: .word L68 .stabd 0104,0,014 jbr L70 L71: .stabs "frame:14",0x80,0,1,-4 .stabd 0104,0,010 .stabs "z2:1",0x80,0,4,-8 .stabd 0104,0,014 .stabd 0300,0,02 .stabs "foo:2",0x80,0,1,-9 .stabd 0300,0,03 subl3 $9,fp,r0 cmpl r0,__ThreadSupport__stackLimit jgtr L72 calls $0,*_runtime+192 L72: .stabd 0340,0,03 .stabd 0104,0,010 cmpd 8(ap),16(ap) jneq L9999 movl $1,r0 jbr L9998 L9999: clrl r0 L9998: movl r0,-8(fp) tstl -8(fp) jeql L73 .stabd 0104,0,012 .data 1 L74: .ascii "\3\0\0\0\22\0\0\0EQUAL INSIDE\12\0" .text pushl $L74+4 pushl __Stdio__stderr pushl $0 calls $3,__Wr__PutText /* no info for if_1_end (7) */ jbr L75 L73: .stabd 0104,0,014 .data 1 L76: .ascii "\3\0\0\0\26\0\0\0DIFFERENT INSIDE\12\0" .text pushl $L76+4 pushl __Stdio__stderr pushl $0 calls $3,__Wr__PutText /* no info for if_1_end (7) */ L75: ret .stabd 0340,0,02 ret _Test9__initProc: .word L78 .stabd 0104,0,032 jbr L80 L81: [...] .data .align 2 L82: .double 0d1.00000000000000000000e-01 .text cvtdf L82,__Test9__tmp .stabd 0104,0,023 .data 1 L83: .ascii "\3\0\0\0\27\0\0\0*** tmp = 0.1 ***\12\0" .text pushl $L83+4 pushl __Stdio__stderr pushl $0 calls $3,__Wr__PutText .stabd 0104,0,024 .data .align 2 L84: .double 0d1.00000000000000000000e-01 .text cvtfd __Test9__tmp,r0 cmpd r0,L84 jneq L9997 movl $1,r0 jbr L9996 L9997: clrl r0 L9996: movl r0,-8(fp) tstl -8(fp) jeql L85 .stabd 0104,0,026 .data 1 L86: .ascii "\3\0\0\0\23\0\0\0EQUAL OUTSIDE\12\0" .text pushl $L86+4 pushl __Stdio__stderr pushl $0 calls $3,__Wr__PutText /* no info for if_2_end (7) */ jbr L87 L85: .stabd 0104,0,030 .data 1 L88: .ascii "\3\0\0\0\27\0\0\0DIFFERENT OUTSIDE\12\0" .text pushl $L88+4 pushl __Stdio__stderr pushl $0 calls $3,__Wr__PutText /* no info for if_2_end (7) */ L87: .stabd 0104,0,031 .data .align 2 L89: .double 0d1.00000000000000000000e-01 .text movd L89,-(sp) cvtfd __Test9__tmp,-(sp) pushl $0 calls $5,__Test9__Funny .stabd 0104,0,032 pushl __Stdio__stderr pushl $0 calls $2,__Wr__Close ret .stabd 0340,0,02 ret If I understand this correctly, it seems that the C compiler interprets 0.1 as a double-precision literal, and therefore evaluates the test "_Test9__tmp == 0.1" by extending tmp to double and doing a double-precision compare. The same thing happens in the call to Funny(). (According to the cc manpage, the "-f" flag will force expressions involving only single-precision operands to be evaluated in single precision. Unfortunately this flag does not affect the doubling of real literals and procedure arguments. Indeed, compiling the program above with "m3 -X1f" still gives the same output.) This behavior of the C compiler seems quite incompatible with the the Modula-3 semantics of REAL vs. LONGREAL. I suppose that the main reason for requiring a "d" for LONGREAL literals in Modula-3 was to prevent exactly this kind of surprises. --jorge ------------------------------------------------------------------------------ Date: 23 Jan 90 16:49:00 PST From: Subject: Fmt.Ref and Fmt.Addr don't work for base = 10. It seems that Fmt.Ref and Fmt.Addr return the empty string for some bases other then 8 or 16: srcf3e 37> m3 -g -o Test010 Test010.m3 srcf3e 38> Test010 tmp = 98160 (hex) (dec) 2300540 (oct) (bin) adr = 98160 (hex) (dec) 2300540 (oct) (bin) srcf3e 39> cat Test010.m3 UNSAFE MODULE Test010 EXPORTS Main; IMPORT Wr, Text, Fmt; FROM Stdio IMPORT stderr; VAR tmp: REF LONGREAL; adr: ADDRESS; BEGIN tmp := NEW(REF LONGREAL); Wr.PutText(stderr, "tmp = " & Fmt.Ref(tmp) & " (hex) " & Fmt.Ref(tmp, 10) & " (dec) " & Fmt.Ref(tmp, 8) & " (oct) " & Fmt.Ref(tmp, 2) & " (bin) " & "\n" ); adr := ADR(tmp^); Wr.PutText(stderr, "adr = " & Fmt.Addr(adr) & " (hex) " & Fmt.Addr(adr, 10) & " (dec) " & Fmt.Addr(adr, 8) & " (oct) " & Fmt.Addr(adr, 2) & " (bin) " & "\n" ); Wr.Close(stderr); END Test010. srcf3e 40> ------------------------------------------------------------------------------ Date: 23 Jan 90 17:41:00 PST From: Subject: Inconsistent spelling: ADR (built-in) vs Fmt.Addr The Subject says it all. --j ------------------------------------------------------------------------------ Date: 25 Jan 90 09:06:04 PST From: zs01+@andrew.cmu.edu (Zalman Stern) Subject: Bug in bounds checking for INC and DEC on addresses. My port of SRC Modula-3 to the IBMRT is coming along well. I have a working compiler and am now letting it chew on the test cases. I'll try and post a long list of notes and diffs in the next couple of days. In the meantime, I think I've found a bug... In compiling test case c065 using my first stage RT compiler, I wind up with code that is unacceptable to High C. The generated code will probably work on PCC based compilers which have looser type checking. However I believe the generated code is incorrect to begin with. Given the following Modula-3 code: UNSAFE MODULE Main; VAR x, y : ADDRESS; BEGIN INC (x, 5); DEC (x, 6); END Main. the compiler renders the following C code: [lines deleted] #define t1 ADDRESS [lines deleted] #line 1 "/tmp/Main.m3" PRIVATE t1 _Main__x; #line 1 "/tmp/Main.m3" PRIVATE t1 _Main__y; [lines deleted] #line 8 "/tmp/Main.m3" PRIVATE void #line 8 "/tmp/Main.m3" Main__initProc () #line 8 "/tmp/Main.m3" { #line 8 "/tmp/Main.m3" scope_1 frame; #line 7 "/tmp/Main.m3" if ((_Main__x += 5 ) > -1) RANGEFAULT; #line 8 "/tmp/Main.m3" if ((_Main__x -= 6 ) < 0) RANGEFAULT; #line 8 "/tmp/Main.m3" return; #line 8 "/tmp/Main.m3" }; Now ADDRESS is a (char *) as we all know. The above code will not pass through the High C on the RT because it attempts to compare char *'s with integers. I thought about throwing in a cast, but it seems like the above code is going to RANGEFAULT for any address that gets passed in. (i.e. almost every address on my machine is greater than -6.) I took a look at Compile in compiler/builtinOps/Inc.m3 and it seems to be doing the wrong thing for "Unbounded" variables. The variables bmin and bmax are getting set to 0 and -1 respectively by the NotBounded routine in compiler/types/TypeRep.m3 . In this case, i would think that Inc should omit the range checking code, but I'm not sure what is supposed to happen... Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 ------------------------------------------------------------------------------ Date: 25 Jan 90 10:14:00 PST From: Subject: Re: Core dump from NARROW(v, REF INTEGER)^ Thanks for the crisp bug report. The work around is to assign the result of NARROW(..)^ to a variable before comparing it. The fix is to change lines 96 & 97 of compiler/exprs/EqualExpr.m3 from ta := p.a.type; tb := p.b.type; to ta := Type.Base (p.a.type); tb := Type.Base (p.b.type); - Bill ------------------------------------------------------------------------------ Date: 25 Jan 90 10:33:00 PST From: Subject: Re: Spurious "recursive declaration" message? Yes, this is a bug. Unfortunately there isn't a simple fix. If you use TYPE Flag = [0..1]; TYPE Bit = BITS 1 FOR Flag; PROCEDURE Foo () = VAR rt := NEW (REF ARRAY Flag OF CARDINAL); BEGIN END Foo; then, the compiler should be happy. - Bill ------------------------------------------------------------------------------ Date: 25 Jan 90 10:42:00 PST From: Subject: Re: MIPS C compiler passes "float" as "double"? Yep. Most C compilers pass floats as doubles. This behavior was defined in old versions of K&R. I don't know what ANSI C says about the auto-magic float/double conversions. Fortunately for those of us writing Modula-3 -> C compilers, LOOPHOLE is unsafe and its results are implementation dependent. I'd like to find the perverse programmer who can detect the difference without using LOOPHOLE. He would be able to demonstrate a bug in our compiler that we would feel obliged to fix. - Bill ------------------------------------------------------------------------------ Date: 25 Jan 90 10:46:00 PST From: Subject: Re: Fmt.Ref and Fmt.Addr don't work for base = 10. Yes. Our original versions of Fmt.Ref and Fmt.Addr simply called C's printf with %d, %o or %x as required. We didn't handle other bases. The next release will correct this bug. - Bill ------------------------------------------------------------------------------ Date: 25 Jan 90 10:51:00 PST From: Subject: Re: Bug in bounds checking for INC and DEC on addresses. Yes, INC and DEC should not do range checking on addresses. My message of 1/22 (Re: Spurious warning on INC(address)) acknowledges the bug and gives a work around and compiler fix. - Bill P.S. Congratulations on your RT port. If you send us your notes and diffs soon, we'll try to include an IBM/RT version of the system in our next release. ------------------------------------------------------------------------------ Date: 25 Jan 90 11:39:00 PST From: Subject: Re: MIPS C compiler passes "float" as "double"? [Bill Kalsow:] I'd like to find the perverse programmer who can detect the difference without using LOOPHOLE. He would be able to demonstrate a bug in our compiler that we would feel obliged to fix. I thought that the example in my next message did just that. If not, consider this: srcf3e 70> cat Test012.m3 MODULE Test012 EXPORTS Main; IMPORT Wr, Text; FROM Stdio IMPORT stderr; PROCEDURE Foo(arg: REAL) = VAR loc1, loc2: REAL; BEGIN loc1 := 0.1; loc2 := 0.1; IF (loc1 = loc2) THEN Wr.PutText(stderr, "loc1 = loc2\n") ELSE Wr.PutText(stderr, "loc1 # loc2\n") END; IF (loc1 = arg) THEN Wr.PutText(stderr, "loc1 = arg\n") ELSE Wr.PutText(stderr, "loc1 # arg\n") END; arg := 0.1; IF (loc1 = arg) THEN Wr.PutText(stderr, "loc1 = arg\n") ELSE Wr.PutText(stderr, "loc1 # arg\n") END; END Foo; BEGIN Foo(0.1); Wr.Close(stderr); END Test012. srcf3e 71> m3 -g -o Test012 Test012.m3 && Test012 loc1 = loc2 loc1 # arg loc1 # arg srcf3e 71> --jorge ------------------------------------------------------------------------------ Date: 25 Jan 90 18:28:00 PST From: Subject: More inconsistent spellings: Fmt.LongReal, Cast.LongrealToInt. --jorge ------------------------------------------------------------------------------ Date: 31 Jan 90 00:55:00 PST From: Subject: no automatic aggregate initialization What does this message mean? srcf3e 4> m3 -g -c Test017.m3 "Test017.m3", line 8: no automatic aggregate initialization "Test017.m3", line 8: operands of = have incompatible types m3: /bin/cc exited, status=1 srcf3e 5> cat Test017.m3 MODULE Test017 EXPORTS Main; TYPE T = RECORD lo, hi: REAL END; VAR a: REAL; BEGIN WITH t = T{1.0, 2.0} DO a := t.lo END END Test017. srcf3e 6> (Compiled with release 1.2 of m3, VAX (Firefly) version) --jorge ------------------------------------------------------------------------------ Date: 31 Jan 90 10:14:24 PST From: bud@ucrmath.ucr.edu (bud mckenzie) Subject: mailing list -- removal Please remove me from the SRC m3 mailing list. Bud ------------------------------------------------------------------------------ Date: 31 Jan 90 14:03:06 PST From: kateley@apple.com (Jim Kateley) Subject: mailing list -- removal Please remove me from the SRC m3 mailing list. Thanks, Jim ------------------------------------------------------------------------------