Date: 31 Dec 90 20:32:40 GMT From: system@syzzle.UUCP (SYSTEM 0PERATOR) Subject: Modula-3 implementations I have been programming in modula-2 under DOS for a while now, and afte r reading the article in BYTE magazine, was looking forward to checking out modula-3. I then read the message saying that Modula-3 required 35M of disk space to implement? I understand that there is another implementation available, is this also as LARGE? Are there any plans to port modula-3 to MSDOS? Thanks for any answers you may have! Al ------------------------------------------------------------------------------ Date: Wed, 2 Jan 1991 13:10:19 PST From: David Goldberg Subject: optimization and garbage collection This is on SPARCs. I compiled the "m3compile" program using cc -O, and when I used the resulting compiler, I got random behavior: when repeatedly compiling the same program, sometimes that program would compile correctly, and sometimes not. When I patched collection_allowed to be 0, compiles always worked. This is true with both gcc (1.37.1) and the Sun C compiler (SparcCompiler 1.1 beta). Has anybody tried compiling m3compile with optimization and gotten it to work reliably? David Goldberg ------------------------------------------------------------------------------ Date: Wed, 2 Jan 91 16:15:55 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Translator to C In article <1990Dec28.130416@ephesus.ncsa.uiuc.edu>, idilber@ephesus.ncsa.uiuc. edu (Ilhan Dilber) writes: > I am looking for the source code for a translator from Modula-3 to C. I > heard it was available > from DEC via anonymous ftp. I downloaded some stuff from their modula3 > directory, but it looks > like it is more than just a translator ( and I don't know if the > translation routine is part of > that). Does anyone know if there is such a translator and where to find > the source? The thing you found on gatekeeper.dec.com is a Modula-3 compiler, its associated runtime, and basic libraries. This compiler happens to generate C code, but it is not a translator to C; i.e. there should be no errors while compiling the resulting C code and little effort has been made to make this C code readable. But may be this is what you really want ? Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Wed, 2 Jan 91 16:26:22 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 implementations In article <6k02u1w163w@syzzle.UUCP>, system@syzzle.UUCP (SYSTEM 0PERATOR) writ es: > > I have been programming in modula-2 under DOS for a while now, and after > reading the article in BYTE magazine, was looking forward to checking out > modula-3. I then read the message saying that Modula-3 required 35M of disk > space to implement? On a DECstation 5000: - 35 Mb to build the system - 8 Mb of permanent storage, including the libraries with the bindings to X, Xt, Xaw which you may not need. > I understand that there is another implementation > available, is this also as LARGE? The other implementation has been developped by the Olivetti Research Center. Unfortunately, this lab is now closed, and I am not sure about the current avaibility of their system. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Thu, 3 Jan 91 11:37:33 EST From: wyant@saber.com Subject: Whither 1.6 Is there a schedule for when SRC Modula-3 1.6 will be ready for beta test yet ? Can you give us a hint of what will be in 1.6 (beyond numerous bug fixes :-) ) ? Cheers, geoff wyant@saber.com ------------------------------------------------------------------------------ Date: Thu, 3 Jan 91 09:49:39 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Modula-3 implementations In article <1991Jan2.162622.8920@src.dec.com>, muller@src.dec.com (Eric Muller) writes: > > The other implementation has been developped by the Olivetti Research > Center. Unfortunately, this lab is now closed, and I am not sure about > the current avaibility of their system. > The Olivetti system is no longer available. Since it requires more machine resources than the SRC compiler, it would not satisfy the original poster's requirements. However, much of the Olivetti system, in particular the AST-based toolkit will find its way into the SRC distribution soon. As of yesterday the 1.6 SRC system successfully built one of my tools for the first time (the tool builds a proforma MODULE from an INTERFACE by AST transformation and subsequent pretty printing). Mick Jordan ------------------------------------------------------------------------------ Date: 3 Jan 91 00:47:39 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: optimization and garbage collection goldberg@parc.xerox.com (David Goldberg) writes: > [with "cc -O" of m3compile, I got random behavior until I turned > off the garbage collector.] Please note that this is very probably not a bug in the optimizer; such behavior was predicted over 3 years ago. This is one of the hazards of using C as an intermediate language. (I'm trying very hard not to gloat too much.) As a workaround, you might try (for Sun's compiler) "cc -O1". David Chase Sun Microsystems, Inc. ------------------------------------------------------------------------------ Date: 4 Jan 91 20:47:59 GMT From: rminnich@super.org (Ronald G Minnich) Subject: Re: optimization and garbage collection In article <5142@exodus.Eng.Sun.COM>, chased@rbbb.Eng.Sun.COM (David Chase) wri tes: |> Please note that this is very probably not a bug in the optimizer; |> such behavior was predicted over 3 years ago. This is one of the |> hazards of using C as an intermediate language. (I'm trying very hard |> not to gloat too much.) Any objection a more detailed explanation? I haven't looked at what this is doing, so am curious. thanks, ron -- "Socialism is the road from capitalism to communism, but we never promised to feed you on the way!"-- old Russian saying "Socialism is the torturous road from capitalism to capitalism" -- new Russian saying (Wash. Post 9/16) ------------------------------------------------------------------------------ Date: 7 Jan 91 16:45:43 GMT From: cjlabrie@cs.ruu.nl (Jan Labrie) Subject: Pointer ? Could anyone reading this newsgroup supply a good pointer to documentation on modula3 ? Any book or article describing modula3 completely is ok. Jan Labrie E-Mail : labrie@cs.ruu.nl ------------------------------------------------------------------------------ Date: 7 Jan 1991 1235-PST (Monday) From: Subject: Re: Pointer ? Brian Guenter and Jeff Templon point to the terseness of the Modula-3 specification and ask if there is any documentation that is more "user-oriented". I afraid there's not much yet; but more is on the way. Sam Harbison's article in the November 1990 issue of BYTE contains a very readable overview together with a few example programs. I believe that reprints of the article are available from Pine Creek Software (840 Canerbury Lane, Pittsburgh PA 15232). I know of three books on Modula-3 in progress, one by Sam Harbison. The one I'm editing will be in the bookstores in about three months; it includes the language specification in its current terse style, but also includes several chapters written in a more expansive style. Research report SRC-53, by Mark Brown and me is available from DEC Systems Research Center, 130 Lytton Ave. Palo Alto, CA. It contains an extended example program implementing I/O streams, but it is in a terse style similar to the report. ------------------------------------------------------------------------------ Date: 4 Jan 91 23:19:14 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: optimization and garbage collection rminnich@super.org (Ronald G Minnich) writes: >David Chase wrote:: >|> Please note that this is very probably not a bug in the optimizer; >|> such behavior was predicted over 3 years ago. >Any objection a more detailed explanation? Nope (and this is the second request, counting e-mail queries, so....) What happens (in broad terms) is this: The C compiler is not required to maintain the variables, as you write them, with the values that you expect to see in them. The variables may be folded into common/loop-invariant/loop-inductive expressions (because it makes the code go faster) and the registers containing the original variables (now dead) are reused for temporaries. These temporaries may contain positive or negative offsets from pointers, or even the difference of two pointers. The garbage collector goes looking for pointers to the beginning of an object, finds none, and reclaims the object (incorrectly). Any temporaries referencing the object are now dangling pointers. Note well that this is correct, standard-conforming, behavior on the part of the (C) optimizer. The garbage collector is relying on artifacts of a particular implementation of C. Those artifacts are not required to exist, were not intended by the compiler writers when they wrote the compiler, and are not checked by a single line of test code. This problem exists whenever you use C as an intermediate language, optimize it, and make use of a conservative stack/register-scanning garbage collector; it is not peculiar to Modula-3. For example, suppose you wrote your own copy of strcpy: char * strcpy (char * s1, char * s2) { int i; for (i = 0; s2[i] != 0; i++) s1[i] = s2[i]; s1[i] = 0; return s1; } This might reasonably be optimized to char * strcpy (char * s1, char * s2) { char * t = s1; while (*s2 != 0) { *s1 = *s2; s1++; s2++; } *s1 = 0; return t; } No memory allocation takes place in the inner loop, so it appears to be ok to toss the pointers to the beginning of the strings. However, the same optimization applies if a procedure is called within the loop, as in: char * tweaked_strcpy (char * s1, char * s2, char (*f)(char)) { char * t = s1; while (*s2 != 0) { *s1 = (*f)(*s2); s1++; s2++; } *s1 = 0; return t; } The procedure f can do whatever it chooses, including allocate memory. And, with preemptively scheduled threads, a garbage collection can occur at any time. David Chase Sun Microsystems ------------------------------------------------------------------------------ Date: Wed, 9 Jan 91 18:43:52 PST From: muller@src.dec.com (Eric Muller) Subject: Re: optimization and garbage collection David Chase argues that an aggressive C optimizer can disturb Modula-3 programs (in the case of a Modula-3 compiler that generates C, of course). In particular, garbage collection can be a real trouble, as roots can be "hidden". While such occurrences are possible, I would not rule out a bug in the Modula-3 compiler or in the C optimizer to conclude right away in favor of an unwanted side-effect of aggressive optimization. If I were to give probabilities to: 1. SRC Modula-3 generates incorrect C code 2. the C compiler is incorrect 3. it is one of those things we cannot do because we generate C I would say: p(1) = 99.9%, p(2) = 0.099%, p(3) = 0.001%. Of course, we make assumptions when generating code and in the garbage collector, and they may not be satisfied. As for the generated code, we try to use no more than what ANSI-C says. For the garbage collector, we assume that if a traced heap object (i.e. a traced OBJECT or REF) is accessible by the program, then there is somewhere in the stacks or the registers a reference to one of the pages that contains that object. If it turns out that this is not reasonable, we can increase the level of conservatism, for example that saying that the pointer can be as far as x bytes from object. However, we have yet to see an example of 3. In the mean time, keep these bug reports coming so that we can achieve p(1) = 50%. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: 11 Jan 91 21:11:43 GMT From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: optimization and garbage collection In comp.lang.modula3, article <5293@exodus.Eng.Sun.COM>, chased@rbbb.Eng.Sun.COM (David Chase) writes: < < The garbage collector goes looking for pointers to the beginning < of an object, finds none, and reclaims the object (incorrectly). < Any temporaries referencing the object are now dangling pointers. < It might be more reasonable to mark the object in use if there is any pointer anywhere into the object. Has anyone tried this and watched whether, for a test case which exhibits the problem, said problem goes away? -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/ ------------------------------------------------------------------------------ Date: 14 Jan 91 01:56:57 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: optimization and garbage collection urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.lang.modula3, article <5293@exodus.Eng.Sun.COM>, > chased@rbbb.Eng.Sun.COM (David Chase) writes: >< The garbage collector goes looking for pointers to the beginning >< of an object, finds none, and reclaims the object (incorrectly). >< Any temporaries referencing the object are now dangling pointers. >It might be more reasonable to mark the object in use if there is any pointer >anywhere into the object. If you think about this a bit, you'll see that you get reference counting, sort of (what if there is more than one pointer "into" the object?). Second problem is, how do you find these objects? Sounds like one more sweep step (since the optimizer hid them from the collector). "Into" is not really "into"; derived pointers may exist outside the object. Optimizing C compilers do this. There is no useful bound on how far "outside" the object the pointer may "point", and no reason that there should be. I think the answer is to get a little bit of help from the compiler; unfortunately (in the short term) you won't get any help from a compiler (or back-end/optimizer) for C. David ------------------------------------------------------------------------------ Date: 14 Jan 91 16:54:53 GMT From: hagerman@ece.cmu.edu (John Hagerman) Subject: Re: optimization and garbage collection David Detlefs just completed his PhD on garbage collection for C++ which addresses the problem of handling member pointers. It might address many of the points being raised here. -- hagerman@ece.cmu.edu ------------------------------------------------------------------------------ Date: 14 Jan 91 23:04:51 GMT From: griffin@sapphire.idbsu.edu (John Griffin) Subject: Need help installing modula-3 on hp9000/400 As a new subscriber to the modula-3 group, I apologize if I'm posting questions which have already been answered. I have attempted to install modula-3 on an HP 9000/400 running hp-ux 7.03 (I'm using HP300 as the system type). I made a few simple changes in C files to achieve compatibility with the C library routines but I have not changed any of the imake files or the ".tmpl" files. The compiler "m3compiler" is not getting generated although the binaries are being produced in subdirectories of .ROOT/system/compiler. I also seem to be having trouble in the generation of the libraries. The following listing shows the archive files (only one of which is nonempty in some cases because of the lack of binaries where it would seem some should have been produced). 8 Jan 13 19:52 ./libs/io/libm3io.a 8 Jan 13 19:56 ./libs/Xt/libm3Xt.a 8 Jan 13 19:54 ./libs/math/libm3math.a 8 Jan 13 19:54 ./libs/misc/libm3misc.a 8 Jan 13 19:55 ./libs/Xlib/libm3X11.a 8 Jan 13 19:56 ./libs/Xaw/libm3Xaw.a 8 Jan 13 19:54 ./libs/ultrix-3.1/libm3ultrix-3.1.a 8 Jan 13 19:54 ./libs/data/libm3data.a 8 Jan 13 19:55 ./libs/aix-ps2-1.2/libm3aix-ps2-1.2.a 8 Jan 13 19:55 ./libs/ibm-4.3/libm3ibm-4.3.a 8 Jan 13 19:55 ./libs/aix-3.1/libm3aix-3.1.a 8 Jan 13 19:55 ./libs/posix/libm3posix.a 8 Jan 13 19:55 ./libs/hpux-7.0/libm3hpux-7.0.a 387034 Jan 13 19:52 ./system/corelib/libm3core.a If someone has some suggestions as to places to look, I'd greatly appreciate any help. Responses can be mailed directly to me at: griffin@opal.idbsu.edu. If there is interest, I will post a summary of the responses. Thanks in advance for any help. John Griffin Math Department Boise State University Boise, Idaho ------------------------------------------------------------------------------ Date: Tue, 15 Jan 91 15:11:35 -0500 From: an288@cleveland.Freenet.Edu (Mark Hittinger) Subject: getting modula3 for sco xenix(386) I've tried to ftp the modula3 archive (yes using binary) and have been unable to uncompress it. I've tried all the compress programs I can find including the ones on Ultrix 4.0. No success. Is there anyone on the list who could send me a copy of the uncompressed tar archive on a reg-u-lar 6250 9 track tape? One more thing, is there anyone who has ported the stuff over to SCO Xenix 386? Thanks much, Mark Hittinger Renlar Systems Inc 2640 Palumbo Drive Lexington, Ky 40509 (606)-266-5414 an288@freenet.cleveland.edu -- Mark Hittinger [answering machine (606)-272-2424 PO BOX 43358 Middletown, KY 40243 ------------------------------------------------------------------------------ Date: Tue, 15 Jan 91 12:29:24 PST From: muller@src.dec.com (Eric Muller) Subject: Re: getting modula3 for sco xenix(386) In article <9101152011.AA29913@cwns2.INS.CWRU.Edu>, an288@cleveland.Freenet.Edu (Mark Hittinger) writes: > I've tried to ftp the modula3 archive (yes using binary) and have been > unable to uncompress it. I've tried all the compress programs I can > find including the ones on Ultrix 4.0. No success. If you use the distribution in pieces (m3-1.5.tar.Z-??), you must first concatenate the files (in the right order), then uncompress. Is that the problem ? ------------------------------------------------------------------------------ Date: 17 Jan 91 20:26:11 GMT From: nr@hart.Princeton.EDU (Norman Ramsey) Subject: Floating point question If x : REAL, under what circumstances am I guaranteed FLOAT(LONGFLOAT(x)) = x? (I'm uneasy about the ``ties are broken arbitrarily'' language in the Definition.) -- Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: 18 Jan 91 02:55:40 GMT From: madmats@elcgl.epfl.ch Subject: Re: Floating point question > If x : REAL, under what circumstances am I guaranteed > FLOAT(LONGFLOAT(x)) = x? I would say Never, in any programming language. I even would think that "=" on floating point numbers should not exist at all, because no formal description can address its semantics correctly without being at the machine level, which is highly undesirable because it would make programs nonportable from, say, VAX to IEEE floating point. Mats ------------------------------------------------------------------------------ Date: 18 Jan 91 03:01:30 GMT From: madmats@elcgl.epfl.ch Subject: modula-3 1.6 on Suns Hello, I have had quite many problems when installing modula-3 1.5 on Sun4's and Sun3's. On the contrary, 1.4 had no problems at all. As 1.6 is in progress, I would like to kindly ask that it be fully tested for these platforms. I realize such a "request" is very hard to fulfill, but it would be great. Mats ------------------------------------------------------------------------------ Date: Fri, 18-Jan-91 11:13:41 EST From: greeny@wotan.top.cis.syr.edu (Jonathan Greenfield) Subject: Re: Floating point question In article <1991Jan18.035540.1@elcgl.epfl.ch> madmats@elcgl.epfl.ch writes: >> If x : REAL, under what circumstances am I guaranteed >> FLOAT(LONGFLOAT(x)) = x? > >I would say Never, in any programming language. I must disagree with this. While some languages and implementations may vary from doing so, I can see no good reason why the set of representable values using single precision should not be a subset of the set of representable values using double precision, regardless of the language. Essentially I am saying that there is no justification for a loss of information due to an INCREASE in precision. While we know that, in general, the laws of algebra to not apply to the manipulation of reals in programs, the law FLOAT(LONGFLOAT(x)) = x (for REAL x, and for the operations specified in the Modula-3 language definition) will hold on any system that provides compatible single- and double-precision reals, as described above. The failure to provide compatible single- and double-precision real representations is undoubtedly a serious flaw for any processor. Based on the language definition, it is clear that the above law will be correct for any implementation using compatible real representations. (Because the statement about 'ties' can only apply when there is no exact equivalent for the type conversion.) Jonathan Greenfield ------------------------------------------------------------------------------ Date: Fri, 18 Jan 91 12:26:00 PST From: muller@src.dec.com (Eric Muller) Subject: Re: modula-3 1.6 on Suns In article <1991Jan18.040130.1@elcgl.epfl.ch>, madmats@elcgl.epfl.ch writes: > I have had quite many problems when installing modula-3 1.5 on > Sun4's and Sun3's. On the contrary, 1.4 had no problems at all. Sorry for the trouble. I made the mistake to make some modifications after the beta test. One of the difficulties of the exercise is that we have only VAX and DECstations here; we have to ask kind souls to test the release on other architectures, and merge the (sometime conflicting) changes without a good way of testing the final result. > As 1.6 is in progress, I would like to kindly ask that it be fully > tested for these platforms. I realize such a "request" is very hard > to fulfill, but it would be great. I will send a message announcing 1.6beta right now. See the rules of the game there. Eric Muller. ------------------------------------------------------------------------------ Date: Fri, 18 Jan 91 13:00:55 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 1.6 beta; gatekeeper reorganization SRC Modula-3 1.6 beta is now available via anonymous ftp on gatekeeper.dec.com, in pub/DEC/Modula-3. The contents of that directory has been reorganized: % ls -R README m3-1.5 report comp.lang.modula3 m3-1.6beta comp.lang.modula3: README aug90.Z dec90.Z jan90.Z jun90.Z may90.Z oct90.Z apr90.Z dec89.Z feb90.Z jul90.Z mar90.Z nov90.Z sep90.Z m3-1.5: README m3-1.5.tar.Z-03 m3-1.5.tar.Z-07 m3-1.5.tar.Z-11 m3-1.5.tar.Z m3-1.5.tar.Z-04 m3-1.5.tar.Z-08 m3-1.5.tar.Z-12 m3-1.5.tar.Z-01 m3-1.5.tar.Z-05 m3-1.5.tar.Z-09 m3-1.5.tar.Z-02 m3-1.5.tar.Z-06 m3-1.5.tar.Z-10 m3-1.6beta: dist-1.6beta.tar.Z report: README Report.ps Report1.ps Report2.ps Report3.ps This release is intended only for those that are ready to invest some time and effort in fixing and testing the release. If you want a "no problems" installation, you should wait for the release of 1.6. The rest of this message tells you about some of the problems you may expect and what you can do to help us get 1.6 ready. First, thanks for your help. Unfortunately we have access only to VAX and DECstations; this limits severely our ability to test the system. This is why your help is very important to get SRC Modula-3 running on other machines and we appreciate it a lot. Second, there are still some glitches for the VAX and DECstations. I decided to go ahead anyway so that we can get 1.6 faster. Here are the known problems: - in both versions, there is a glitch in the construction of the yacc parser for m3pp. Part of the trouble is that we need a larger-than-normal yacc; normally, we process the yacc file and give the result, but the construction process wants to build it again. - in both versions, the Imakefiles for the tests use the "-g" option. This is option is no longer supported by "m3", as different C compiler have different syntaxes for the debugging/optimization. Instead, one should use something like -X1-g or -X1-g3. I'd like to hear about what the best thing to do is: is the current situation the right solution or should be have an entry in the config file that indicate with options should be passed to cc when -g is given to m3 ? or - in the VAX version, thread switching is broken, but does not prevent the execution of non-threaded programs (such as the compiler itself). - in the AP3000 version, thread switching is broken. It is a bit worse than in the VAX case, in that it probably prevents linking of Modula-3 programs, but I believe that the basic machinery is sound. Of course, I am fixing the problems for VAX and DECstations. Third, this release fixes the alignment problems. However, this means that the C code generated is much more sensitive to the size, alignment and structure layout parameters present in system/compiler/misc/Target.i3.. I hope we got these and structure layout algorithm (in system/compiler/types/RecordType.m3) right. If it is not the case for the architecture you are testing and you don't have 1.5 running, there is little you can do, as it is next to impossible to edit all the .{i,m}c files by hand; the best in that case is that you tell me the right numbers/algorithm and I regenerate the .{i,m}c files. If you have 1.5 running, you can use it to recompile 1.6beta from the .{i,m}3. By the way, 1.5 can compile 1.6beta, it is actually the version I am using to compile the cross-compilers that produced the .{i,m}c of the release. Fourth, the driver has been completely rewritten so that we can support shared libraries. However, there is still a fair amount of work to actually have shared Modula-3 libraries (Ultrix does not have shared libraries and anyway the mechanism depends on the architecture). Please send the messages about problems/modifications to m3-request@src.dec.com. I will summarize to comp.lang.modula3 as we go along. ------------------------------------------------------------------------------ Date: 18 Jan 1991 2308-PST (Friday) From: Subject: Re: Floating point question > [N. Ramsey:] If x : REAL, under what circumstances am I guaranteed > FLOAT(LONGFLOAT(x)) = x? > [Mats:] I would say Never, in any programming language. The IEEE floating point standard requires that the set of single-precision values be a subset of the double-precision ones (viewed as rational numbers, of course, not as bit patterns). I believe it also requires that rounding errors for common operations be strictly less than one bit in the last position, and that the sign be preserved even when x is 0.0. It follows that both the LONGFLOAT and the FLOAT must involve no rounding, so that FLOAT(LONGFLOAT(x)) is exactly the same bit pattern as x. In fact, I don't know of any machine, IEEE or not, in current use or not, where FLOAT(LONGFLOAT(x)) is not equal to x. > [Mats:] I even would think that "=" on floating point numbers > should not exist at all, because no formal description can address > its semantics correctly without being at the machine level This is not quite true. While the semantics of "=" for floating-point may be a bit messy, even (or especially) in IEEE systems, it is usually much cleaner than that of "+", "*", or even "<" and "0.1". So, by your argument floating-point types should not exist at all. By the way, note that if you cannot say anything concrete about the semantics of "=" for floating-point numbers, then you can hardly say anything about the other relations ("<", "<=", etc.). For instance, when does "(x <= y) AND NOT (x < y)" evaluate to TRUE? According to the Twelve Changes, "=" in IEEE machines will be the IEEE equality predicate, which is just equality of the bit patterns, except that -0.0 = +0.0 is true, and NaN = NaN is false. (Between us, I think this semantics is ugly, and that the inclusion of minus zero in the IEEE standard was one of the most deploarble blunders in the history of computing; but now there's nothing to be done about it.) On non-IEEE floating-point systems, the definition of "=" shouldn't be much more complicated than this. Even though most computed floating-point values are inaccurate, there are many contexts in which it makes sense to compare them for exact equality. For example, log(abs(x)) is well defined for all finite floating-point values x except 0.0; so, testing "x = 0.0" before computing that formula is a pretty sensible thing to do. As another example, if you are incrementing a variable x with a variable step h, you can check whether the step is too small to be subdivided further by testing whether x = x + h/2; this trick is used routinely in numerical integration and root finding algorithms. And so on. There may well exist computers where the floating-point comparison instruction is buggy, and fails to distinguish two numbers when they are too close together. Even if such machines exist, I don't see why the designers of Modula-3 should worry about them: it is those machines who need to be fixed, not the language. --jorge ------------------------------------------------------------------------------ Date: 19 Jan 91 13:56:04 GMT From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Subject: Re: Floating point question >>>>> On 19 Jan 91 07:08:00 GMT, stolfi (Jorge Stolfi) said: > [N. Ramsey:] If x : REAL, under what circumstances am I guaranteed > FLOAT(LONGFLOAT(x)) = x? Jorge> In fact, I don't know of any machine, IEEE or not, in current use or Jorge> not, where FLOAT(LONGFLOAT(x)) is not equal to x. I would not guarantee that the desired behavior would be observed on a Cyber 205/ETA-10. Although the FP formats *appear* to make 32-bit a subset of 64-bit, there are occasional cases where counterintuitive behavior has been observed. An example is in the "paranoia" arithmetic test suite where the Cyber 205/ETA-10 fail a test equivalent to (240/30.eq.8). Note that these are *integer* values, which exist as unnormalized 64-bit floating-point numbers on these machines..... I hope no one is trying to get Modula-3 up on an ETA-10!!!! -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET ------------------------------------------------------------------------------ Date: Mon, 21 Jan 91 11:40:59 PST From: muller@src.dec.com (Eric Muller) Subject: Re: SRC Modula-3 1.6 beta David Goldberg detected the following problem with 1.6 beta: In the driver, ./system/driver/m3.c, the main function should start with a call to "init_base ();". Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: 21 Jan 91 11:53:27 From: nichols@parc.xerox.com (David Nichols) Subject: a couple of questions I couldn't find an analog to the C "continue" statement in M3. What was the committee's reason for leaving this out (or was it just overlooked)? Are TEXTs supposed to be immutable? Would an implementation similar to Cedar Ropes be resonable (except for clients of TextF, of course)? David ------------------------------------------------------------------------------ Date: Mon, 21 Jan 91 16:51:54 PST From: muller@src.dec.com (Eric Muller) Subject: Re: SRC Modula-3 1.6 beta Mick Jordan detected the following problem with 1.6 beta: In ./system/driver/Imakefile, a line is missing at the very end: do_install (m3ar,$(BINDIR), 755) Eric. ------------------------------------------------------------------------------ Date: Tue, 22 Jan 91 18:02:22 PST From: muller@src.dec.com (Eric Muller) Subject: Re: SRC Modula-3 1.6 beta Jorge Stolfi detected the following probleam with 1.6 beta: In system/runtime/M3Runtime.c, in the function main, just after the call to user_main, add the following: exit (0); Eric. ------------------------------------------------------------------------------ Date: 23 Jan 91 09:45:55 GMT From: pr@cl.cam.ac.uk (Peter Robinson) Subject: Compiler confusion between TEXT and ARRAY OF CHAR The following program: | MODULE Main; | | PROCEDURE p (a: ARRAY OF CHAR) = | BEGIN END p; | | BEGIN | p ("a"); | | END Main. causes the DEC SRC Modula-3 compiler (version 1.5, MIPS/Ultrix system) to fail with: | runtime error: ASSERT failed ------------------------------------------------------------------------------ Date: 23 Jan 91 10:33:40 GMT From: pr@cl.cam.ac.uk (Peter Robinson) Subject: Problem with recursive objects The following program: | MODULE Main; | | TYPE r = r OBJECT METHODS m () END; | | BEGIN | END Main. causes the DEC SRC Modula-3 compiler (version 1.5, MIPS/Ultrix system) to loop indefinitely. If the type declaration omits the method: | TYPE r = r OBJECT METHODS END; then a proper error message about a recursive type declaration is given. - Peter Robinson. ------------------------------------------------------------------------------ Date: Wed, 23 Jan 91 22:26:13 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Compiler confusion between TEXT and ARRAY OF CHAR Fixed in 1.6beta. Thanks for the report, Eric. ------------------------------------------------------------------------------ Date: 23 Jan 91 22:11:59 From: janssen@parc.xerox.com (Bill Janssen) Subject: Instance initialization in Modula-3? When defining an OBJECT type in Modula-3, how does one specify the initialization routine to be called from inside NEW? And is there any way to control allocation on a class basis, or does NEW always create new objects on the heap? Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304 ------------------------------------------------------------------------------ Date: 24 Jan 91 13:31:10 GMT From: templon@copper.ucs.indiana.edu (jeffrey templon) Subject: Second Request for Information about Modula-3 I'll try again since only part of my first request for information was answered. Thanks to those who answered the part about where I might find a more readable introduction to Modula-3. A related question is "can i learn anything that would be helpful in mod-3 when learning mod-2?" i found a free mod-2 compiler for all the machines i now work with and their are several books about the language. back to the main question: can someone give a rundown of what machines modula-3 currently runs on? in particular i am interested in the DEC VAX VMS system - i noted that the DEC/Modula-2/m2.vax.tar.Z on gatekeeper contains some VMS support, does the Modula-3 system as well? - and in the Apple Macintosh SE (no 68030/68882 required.) maybe if someone is even WORKING on these they could drop a note. jeff ------------------------------------------------------------------------------ Date: Thu, 24 Jan 91 12:22:22 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Instance initialization in Modula-3? In article , Bill Janssen asks: > When defining an OBJECT type in Modula-3, how does one specify the > initialization routine to be called from inside NEW? Modula-3 does not allow you to attach to an object type code to executed when an object of that type is created. The only thing you can do in the type declaration is to specify default initial values for the fields, which must be constant expressions, and default methods. > And is there any way to control allocation on a class basis, or > does NEW always create new objects on the heap? NEW always create new objects on the traced or untraced heap (depending on the object type). Eric Muller. ------------------------------------------------------------------------------ Date: 24 Jan 91 18:46:25 GMT From: nr@hart.Princeton.EDU (Norman Ramsey) Subject: translating SEGV signal into m3 exception When my (unsafe) m3 program causes a segmentation fault, I would like a signal handler to raise a Modula-3 exception. I've looked at Usignal.i3, but I've always used signal(3) instead of sigvec(2), so I don't know how to proceed. In particular I don't know how to set sv_mask and sv_flags. I'm also not sure how to find the bad address so I can indicate in my exception what address caused the fault. Any suggestions would be appreciated. -- Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: Thu, 24 Jan 91 14:08:55 PST From: Subject: Re: Instance initialization in Modula-3? The convention used in Trestle (the Modula-3 window toolkit) is that each object type has an "init" method that returns the object after initializing it. So you can type VAR v := NEW(T).init(args) to allocate and initialize an object of type T. If T has a supertype S, and S uses the same convention, then T.init typically contains the call EVAL(S.init(self)), to initialize the supertype. This style won't work with SRC Modula-3 1.6, which doesn't let you NEW an opaque type; but it will work soon. There is more discussion about this issue in the "twelve changes to Modula-3" message. Greg ------------------------------------------------------------------------------ Date: Thu, 24 Jan 91 18:54:51 PST From: muller@src.dec.com (Eric Muller) Subject: Re: translating SEGV signal into m3 exception In article <6291@rossignol.Princeton.EDU>, nr@hart.Princeton.EDU (Norman Ramsey ) writes: > When my (unsafe) m3 program causes a segmentation fault, I would like > a signal handler to raise a Modula-3 exception. I've looked at > Usignal.i3, but I've always used signal(3) instead of sigvec(2), so I > don't know how to proceed. Look at the body of system/corelib/runtime/RTMisc.m3. Eric Muller. ------------------------------------------------------------------------------ Date: 25 Jan 91 15:57:49 GMT From: pierson@encore.com (Dan L. Pierson) Subject: Re: Instance initialization in Modula-3? Regarding Re: Instance initialization in Modula-3?; gnelson (Greg Nelson) adds: > The convention used in Trestle (the Modula-3 window toolkit) is that ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hmmm, interesting, please post more info. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com ------------------------------------------------------------------------------ Date: Fri, 25 Jan 1991 09:51:55 PST From: Matthew Chalmers Subject: oddness with 2-d arrays (P.S.) Umm... forgot to say we are using m3 v.1.5. --mjc ------------------------------------------------------------------------------ Date: 25 Jan 91 18:26:03 GMT From: krey@i30fs1.ira.uka.de (Andreas Krey) Subject: Re: Instance initialization in Modula-3? In article <1991Jan24.122222.9214@src.dec.com>, muller@src.dec.com (Eric Muller) writes: > In article , Bill Janssen asks: > > > When defining an OBJECT type in Modula-3, how does one specify the > > initialization routine to be called from inside NEW? > > Modula-3 does not allow you to attach to an object type code to > executed when an object of that type is created. > So why not? For me C++'er it's lot of a reason not to use modula-3. .signature: No such file or directory ------------------------------------------------------------------------------ Date: Fri, 25 Jan 1991 09:50:38 PST From: Matthew Chalmers Subject: oddness with 2-d arrays Hi - Concatenated below are a number of files which collectively show something I don't understand with passing arrays to a procedure in a module. The difference seems to be whether arrays are passed as open or of fixed length (c.f. foo.proc1 and foo.proc2). The output of the collected code is just below, and this shows the wierdness: only 3 longreals copied across(?) instead of 6. Main: 1 2 3 4 9 8 proc1 1 2 3 4 9 8 proc2 1 2 3 4.55779D-309 4.24399D-314 1.37939D-318 I had expected proc2 to output the same thing as proc1. Regards, Matthew Chalmers (*-------------------- cut here -------------------- *) INTERFACE foo; TYPE TwoVec = ARRAY [0..1] OF LONGREAL; PROCEDURE proc1 (p : ARRAY [0..2] OF TwoVec); PROCEDURE proc2 (p : ARRAY OF TwoVec); END foo. MODULE foo; IMPORT Wr, Stdio, Fmt; PROCEDURE proc1 (p : ARRAY [0..2] OF TwoVec) = BEGIN Wr.PutText(Stdio.stdout,"\nproc1\n"); FOR i := 0 TO NUMBER(p)-1 DO Wr.PutText(Stdio.stdout," " & Fmt.LongReal(p[i][0])); Wr.PutText(Stdio.stdout," " & Fmt.LongReal(p[i][1]) & "\n"); END; END proc1; PROCEDURE proc2 (p : ARRAY OF TwoVec) = BEGIN Wr.PutText(Stdio.stdout,"\nproc2\n"); FOR i := 0 TO NUMBER(p)-1 DO Wr.PutText(Stdio.stdout," " & Fmt.LongReal(p[i][0])); Wr.PutText(Stdio.stdout," " & Fmt.LongReal(p[i][1]) & "\n"); END; END proc2; BEGIN END foo. MODULE Main; IMPORT Wr, Stdio, Fmt; IMPORT foo; VAR points : ARRAY [0..2] OF foo.TwoVec; VAR x, y : LONGREAL; BEGIN x := 1.0d0; y := 2.0d0; Wr.PutText(Stdio.stdout, "Main:\n"); FOR i := 0 TO 2 DO points[i][0] := x; points[i][1] := y; Wr.PutText(Stdio.stdout, " " & Fmt.LongReal(x)); Wr.PutText(Stdio.stdout, " " & Fmt.LongReal(y) & "\n"); x := x * 3.0d0; y := y * 2.0d0; END; foo.proc1 (points); foo.proc2 (points); END Main. ------------------------------------------------------------------------------ Date: Fri, 25 Jan 91 18:49:32 GMT From: harrison@darwin.pa.dec.com (Stephen Harrison) Subject: Re: oddness with 2-d arrays Matthew Chalmers reported a problem with 2-D arrays in SRC Modula-3, v1.5. I tried his example with SRC Modula-3, v1.6beta and it works fine. Regards, /Stephen -- Stephen Harrison | harrison@decwse.dec.com Advanced Technology Development | Digital Equipment Corporation | work (415) 853-6747 100 Hamilton Avenue, Palo Alto, CA 94301 | home (408) 739-7734 ------------------------------------------------------------------------------ Date: Fri, 25 Jan 91 13:46:05 PST From: Subject: Re: Instance initialization in Modula-3? Dan L. Pierson asks about the Trestle window toolkit. Trestle is a Modula-3 toolkit for the X window system. It will be released for beta-test in February. There is an extensive tutorial on Trestle in Chapter 7 of "Systems Programming in Modula-3", which is now being printed by Prentice Hall. ------------------------------------------------------------------------------ Date: Fri, 25 Jan 91 13:52:45 PST From: Subject: Re: Instance initialization in Modula-3? Andreas Krey asks why Modula-3 does not automatically invoke an initialization method when an object is allocated. This issue is discussed in the "twelve changes" message sent to this bboard a month ago (19 Dec), and also more briefly in my message of 12 Jan. ------------------------------------------------------------------------------ Date: 26 Jan 91 02:10:46 GMT From: terry@unx2.ucc.okstate.edu (Terry J. Klarich) Subject: Is there Modula3 for sysv? Is there a version of Modula3 for sysv? -- ------------------------------------------------------------------------------- - Terry Klarich (terry@unx2.ucc.okstate.edu) n5hts ------------------------------------------------------------------------------ Date: Sat, 26 Jan 91 01:38:22 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Is there Modula3 for sysv? In article <1991Jan26.021046.21228@unx2.ucc.okstate.edu>, Terry Klarich asks: > Is there a version of Modula3 for sysv? As far as I know, there is only one implementation of Modula-3, free or not, available right now: SRC Modula-3. It runs on various U**X machines, but all are BSD like. I don't know how difficult it would be to port it to System V. Eric. ------------------------------------------------------------------------------ Date: 24 Jan 91 10:43:53 GMT From: pr@cl.cam.ac.uk (Peter Robinson) Subject: Problem with recursive type definition The following Modula-3 declaration: | TYPE r = RECORD p: PROCEDURE (): r END; causes the DEC SRC Modula-3 compiler (version 1.5, MIPS/Ultrix system) to generate faulty C code: | ... | typedef struct { t2 _p; } t1; typedef void (*t2)(); | ... where the use of t2 before its declaration is deemed to be a syntax error. [I assume that the occurrence of r inside its expansion counts as being within a PROCEDURE type constructor, and so is legal code. If r is the type of an argument to the procedure rather than its result, all is well.] Curiously enough, putting a REF before the RECORD declaration does not help, but the code for the analagous | TYPE r = OBECT METHODS p (): r END; is just fine. - Peter Robinson. P.S. Sorry about this burst of trivia - I am just giving my Modula-3 course to a new class of students with a different set of idiosyncracies in their programming styles. Unfortunately, I am also a little nervous about ------------------------------------------------------------------------------ Date: 28 Jan 91 15:41:40 From: janssen@parc.xerox.com (Bill Janssen) Subject: Re: Instance initialization in Modula-3? In article <1991Jan24.122222.9214@src.dec.com> muller@src.dec.com (Eric Muller) writes: Modula-3 does not allow you to attach to an object type code to executed when an object of that type is created. Yes. As a workaround, I've decided to create a base class that defines Make(), which is then the new "standard" way of creating an instance. Make() will call the standard methods Allocate() and Initialize(), which can then be appropriately overridden by the subclass implementor. Thanks. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304 ------------------------------------------------------------------------------ Date: Mon, 28 Jan 91 17:02:38 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Instance initialization in Modula-3? In article , janssen@parc.xerox.co m (Bill Janssen) writes: > Yes. As a workaround, I've decided to create a base class that > defines Make(), which is then the new "standard" way of creating an > instance. Make() will call the standard methods Allocate() and > Initialize(), which can then be appropriately overridden by the > subclass implementor. I am not sure I understand your solution. I believe that you will have some problems with the type declarations and/or have to do some (maybe implicit) narrowing. Can you tell more ? Eric. ------------------------------------------------------------------------------ Date: Tue, 29 Jan 91 16:03:57 GMT From: Marc Wachowitz Subject: language change wishes / Olivetti Modula-3 info needed Note: Since I have no curly braces here, I use "(." and ".)" instead. 1) Behaviour of NEW on lack of dynamic memory The behaviour of NEW when there is insufficient memory available should be specified. The SRC-Compiler (1.5) gives a runtime error. I feel the following solution would be more practical: INTERFACE New; EXCEPTION NoMemory; (* Exception raised by NEW when there is not enough memory *) TYPE NoMemoryAction = (. ReturnNIL, RaiseException, AbortProgram .); (* Action taken when NEW cannot perform its task: ReturnNIL : Just return NIL RaiseException: Raise NoMemory AbortProgram : Abort program execution (current behaviour) *) PROCEDURE GetNoMemoryAction() : NoMemoryAction; PROCEDURE SetNoMemoryAction( action: NoMemoryAction ); (* Get/set bahaviour of NEW on lack of memory. The default behaviour should be AbortProgram, since this does not require the attention by "innocent" programns *) END New; This point might not be that important on machines with large virtual memory, but I think it should be possible to implement the language even on small systems (e.g. only a few MB non-virtual memory). It would definitely not be acceptable for an application program to crash just because it cannot allocate a buffer for a file to be opened :-( 2) UNTRACED types It would be useful to allow the following, which is syntactically illegal: TYPE ObjectType = OBJECT (* ... *) END; UntracedObjectType = UNTRACED ObjectType; (The desired meaning should be obvious.) Currently one must repeat the entire object type definition, preceded by UNTRACED. Though this is of course no problem (given a reasonable editor), it seems error prone when ObjectType comes from a different interface and changes are made in the original type definition. Allowing the given form (and defining it as shorthand for the now required expanded form) should not cause any problems. Similar arguments apply to reference types and BRANDED types, though the latter seems not that important. 3) Information on the Olivetti implementation I would like to get information about the Olivetti implementation of Modula-3: legal status, availability, required hard-/software, form of compilation (e.g. Modula-3 to C like the DEC implementation ?) etc. ------------------------------------------------------------------------------ Date: 29 Jan 91 19:12:16 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: language change wishes / Olivetti Modula-3 info needed I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU (Marc Wachowitz) writes: >2) UNTRACED types >It would be useful to allow the following, which is syntactically >illegal: > >TYPE ObjectType = OBJECT (* ... *) END; > UntracedObjectType = UNTRACED ObjectType; > >(The desired meaning should be obvious.) It's sort of obvious. Presumably, you would be rewriting all of the code (e.g., procedures bound to methods) referenced by this shorthand declaration? The old code almost certainly would not be correct because... It's unlikely that the old (traced) code would contain the bookkeeping necessary to manually maintain the storage. In my experience, interfaces in a garbage-collected world look "sloppy" to people not accustomed to working with a garbage collector (because the interfaces don't contain the extra gunk needed to manage resources between modules and users of the module). It is painful to rewrite code for untraced use, but if you really take advantage of the garbage collector in the traced world, then a port to the untraced world won't be trivial (and if you don't take advantage of the garbage collector, you're throwing away a useful tool). >3) Information on the Olivetti implementation >I would like to get information about the Olivetti implementation of >Modula-3: legal status, availability, required hard-/software, form of >compilation (e.g. Modula-3 to C like the DEC implementation ?) etc. Mick Jordan has the latest word on the legal status. I think it could become available if someone thought it was worth their time. It requires a C compiler, and has been ported to a number of 32-bit machines. The compiler generates (very ugly looking) C. The back-end, which generates that C, is no longer supported, unless someone else wishes to take on the job. It should be cleaned up and rewritten in Modula-3; the current code shows signs of haste, porting, and multiple language changes. I should know; I wrote it. David Chase Sun ------------------------------------------------------------------------------ Date: Tue, 29 Jan 91 15:00:05 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: language change wishes / Olivetti Modula-3 info needed The Olivetti implementation has been cleared for distribution with a simple copyright notice and no licence. However, there is no virtue in distributing the original system since it offers no advantages over the DEC SRC implementation at the level of the generated code. The value of the Olivetti system is the AST-based compiler front-end and other tools that are based on ASTs. This part of the system (somewhat enhanced from the original distribution) will be made available with the SRC distribution sometime during the first half of this year. You will need SRC Modula-3 V1.6 or later to compile it. Mick Jordan ------------------------------------------------------------------------------ Date: 30 Jan 91 13:17:53 GMT From: siebren@rivm.nl (Siebren van der Zee) Subject: Re: language change wishes (how should NEW fail?) In article <9101291633.AA07621@decpa.pa.dec.com> I403%DMAFHT1.BITNET@CUNYVM.CUN Y.EDU (Marc Wachowitz) writes: >(* Get/set bahaviour of NEW on lack of memory. > The default behaviour should be AbortProgram, since this does not > require the attention by "innocent" programns *) I don't think you should do it that way. How can I - after calling any library function - know for sure the behaviour of new is still as it was before the call? And should the behaviour of NEW for the other threads change as well? I don't think state like this should be global. Alternatively, one could pass the behaviour as a parameter to NEW. By supplying a default for this parameter, you can make the change compatible with old programs. Siebren ------------------------------------------------------------------------------ Date: 30 Jan 91 20:37:24 GMT From: nr@elan.Princeton.EDU (Norman Ramsey) Subject: new syntax for overriding method defaults It occurs to me that this new syntax (OBJECT ... OVERRIDES ... END) could also be used to override the default values of data fields. I would find such a facility useful. Can the language definition people comment, or has the definition already gone to press? -- Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: Thu, 31 Jan 91 15:04:17 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3, 1.6beta3 available. A new beta release of SRC Modula-3 1.6 is available via anonymous ftp on gatekeeper.dec.com, in pub/DEC/Modula-3/m3-1.6beta. Corrected problems: - patch is no longer used to rebuild some of the machine specific files. Instead, we generate ed scripts. (There seems to be a problem between GNU diff and patch on some machines). - a few bugs have been fixed, in particular in the heap management. Thanks to David Goldberg, Norman Ramsey, Piet van Oostrum, Dick Orgass and Michael Wells for their comments about 1.6beta. -- Eric. ------------------------------------------------------------------------------