Date: 5 Jul 1990 1436-PDT (Thursday) From: Subject: Re: m3 flags, M3DEFPATH and M3OBJPATH The revised proposal certainly cleans up and improves the definition of the -D option, but I question whether preserving the D option at the expense of the M3PATH is actually the correct thing to do. First, I would observe that, for large-scale development (i.e. any project which has its own libraries), having to set the -D switch on each compilation is an impossible pain. This suggests that the use of a (I)makefile which contains the -D setting will be essential. Actually, its sometimes convenient to run the compiler on a single module, and then let make tidy up, but in either event there is the question of how this makefile gets built. I, like Dick Orgass, believe that a makefile that doesnt record exact dependencies is worthless, and that this can only be done properly automatically from the source. If you accept this argument then there has to be a way to specify which packages you are using so that a tool can generate the makefile. Of course, one could use a -D switch to the tool, but my experience tells me that this information needs to be recorded somewhere if only because, ultimately it gets to be a pain having to (manually) give this information to the makefile generator. The obvious way to do this is in an editable text file (m3path) in the directory in which the program or package is being built. It should be obvious that the file is closer in spirit to the M3PATH variables than the -D switches, and has the virtue of persistence. Indeed I have operated in a world where the environment variables got set from the file as a performance optimisation but I now question the significance of this. Its certainly a pain to switch between programs and forget to reset the variables. Those of you familiar with the Olivetti system will not find it suprising to find me making this argument, but I would be interested to hear the opinions of others. It is relevant since I am reworking the Olivetti makefile generator (m3dep) to work with the SRC compiler. So far I have stuck with an m3path, and generate -D switches in the makefile. I could add a -D switch to m3dep, but I cant imagine wanting to use it myself. And I would prefer it if the SRC compiler went along with the m3path scheme. Mick Jordan ------------------------------------------------------------------------------ Date: Fri, 6 Jul 90 11:46:15 -0500 (CDT) From: Dick Orgass Subject: Re: m3 flags, M3DEFPATH and M3OBJPATH It should be no surprise to readers of this BBoard that I strongly agree with Mick Jordan's comments about building substantial programs in Modula-3. I think our specifications for a build procedure are still a bit incomplete. I'd like to offer some specifications and describe an approach to meeting these requirements. In my comments, I take it for granted that file systems are reorganized every six to nine months and that software sent from one location to another will almost always be in the wrong place for the receiving location. I think this will remain true for a good number of years even if the global file system promise of the AFS component of OSF/DCE is essentially universally implemented. I see two forces pushing against each other: (1) When working on small programs, one doesn't want to do much of anyting and a make file, if needed, should be trivial to create. Among other things, this means that people doing such work need not pay any attention to details like the location of the libraries shipped with the system and which ones are needed. This simplicity is useful for programmers with some experience programming in Modula-3 and is essential for people who are just learning to use Modula-3. (2) When maintaining a larger piece of software, e.g., the Modula-3 distribution, additional requirements are added: (a) It must be possible to change everything about the build in one place, very close to the top of the build tree. This includes things like compiler options, compilers to be used, location of source and object files, search paths, etc. (b) If a source file anywhere in the tree is changed or if new source files are added to the tree, all of the relevant make files must be automatically updated to reflect the new dependencies. Of course, appropriate recompiliations have to occur. (c) When building for multiple targets, the creation of the required target specific directories is to be a side effect of the build. (d) Symbolic links are to be avoided whenever possible. When they must be used, relative paths are to be in the links. (e) Compiler error messages are to name files by a relative path name that begins in the directory where make (or imake) is invoked. (f) The build process may not depend on the location of the root of the source and target trees. At the moment, neither the imake process used for SRC Modula-3 nor the m3dep build process for Olivetti Modula-3 meets all of these requirements; they are hard. I think the m3dep approach comes closest. Let me explain why. A small change to m3dep would be sufficient to satisfy requirement (1). This change is to modify m3dep so that the standard library directories are searched even if they are not mentioned in file m3path so that m3path isn't needed for small programs. The imake approach as described and/or implemented to date does not satisfy the requirement because dependencies do not appear in the imake generated make files. It could satisfy this requirement if a Modula-3 equivalent of makedepend were available and if the imake generated make file would be retained and force a recreation of the make file if anything changes. Early this year, I wanted to modify the make files for Olivetti Modula-3 to meet the requirements in (2). I wasn't completely successful but came close enough that I think this is a possible route. Let me describe what I did and have left undone so that others can tell me what is wrong with the approach. My first attempt was to use BSD 4.3 make and the VPATH macro. The make invocations in the top level make file quickly became so complex that it was clearly the wrong approach. I then went to GNU make and got very much closer to the desired result. [Skip this paragraph if you know about GNU make.] GNU make provides include files, string processing, conditional inclusion of text in make files and a vpath directives which are extension specific. That is, one can specify different search path for .i3 files, for .io files, and so forth. The compilation commands executed by GNU make use the expanded file name. It is upward compatible with both BSD 4.3's make and System V.2's make. The first thing I did was to put all of the macro definitions and rules into an include file and remove them from the individual make files. This made it possible to change many of the details of the build from the top of the source tree. Using GNU make conditionals, I had one set of make files for two targets and could easily add more. The second change that I made (to all of the make files) was to replace the references to files in other directories with vpath definitions for each of the relevant extensions. As a result of these changes, there was no need for symbolic links for source files from a target specific directory to the source directories. Because of the way I specified the vpath directives, all error messages were are in terms of absolute paths to the source files. If I had thought of Eric's .ROOT links, they would have been relative. [I don't know how to accomplish this with imake and a conventional make program; Eric may well have better ideas.] To keep the make files in the source tree, I modified the top level make file to specify the make file for subordinate invocations of make. I also modified the top level make file to create the target specific object directories. At this point, I had a quite convenient multi-target build tree but it did not satisfy all of the requirements in (2) and I view the result as a basis for a design of a build process that meets all of the requirements. I haven't finished the work but I'll describe what I would like to find time to do. Of course, the first thing to do is to modify m3dep to generate GNU make files as described above. This would include using a default include file or an include file specified on the command line. The fact that m3dep uses file m3path in the directory in which it is invoked makes it difficult to centralize the search paths. This could be done with symbolic links to the top level directory but I would prefer to have m3dep accept a -D option so that macros can be placed in the global include file for GNU make. I would modify m3dep so that it generates a rule for GNUmakefile in such a way that this file depends on all the Modula-3 source files (as *.[im]3) in all the directories in the search path passed to m3dep with a -D option. Of course, a new GNUmakefile (in the source tree) would be generated when necessary followed by an invocation of make on the new file. I still don't have a good idea for automatically generating the top level make file. I suppose that one could walk the source tree looking for directories and use the result to generate the top level GNUmakefile but seems to be rather crude. Discussion I described the above approach to a few people from the X Consortium after the imake tutorial at Xhibition. The impression I got from the comments that were made is that they view an approach like this as better than the imake route. However, they did not want to use it because it would mean that their builds would require GNU make which might not be available everywhere. The same issue should be considered for Modula-3. A few years ago, I started on an implementation of a variant of the Lampson-Schmidt Df tools for use with Modula-2 but never finished the job. I did get it far enough along to be able to generate make files for Modula-2 but never went far enough to automate RCS check-in/check-out and installation. As a long term objective, something along these lines might be a better solution than using make. There's a lot of work involved in doing something like this and it's not at all clear that I'll ever have time to do the job. Dick PS If anyone who has an Olivetti Modula-3 license wants a copy of the GNU make files that I described above, I'll be glad to send them. If you ask for them and have a license, please say that you have a license for Olivetti Modula-3 in your note so that I can comply with the license that we signed. ------------------------------------------------------------------------------ Date: 6 Jul 1990 1358-PDT (Friday) From: Subject: Re: m3 flags, M3DEFPATH and M3OBJPATH > (1) When working on small programs, one doesn't want to > do much of anyting and a make file, if needed, should be > trivial to create. Among other things, this means that > people doing such work need not pay any attention to details > like the location of the libraries shipped with the system > and which ones are needed. > > This simplicity is useful for programmers with some > experience programming in Modula-3 and is essential for > people who are just learning to use Modula-3. I agree with this in principle, I just disagree with how the simplicity is to be achieved. In the SRC system I believe that the simplicitly is too hard-wired. It doesnt extend gracefully to encompass user libraries. An alternative would be, for example, to create a Modula-3 environment (shell perhaps) that achieved the same simplicity. > A small change to m3dep would be sufficient to satisfy requirement (1). > This change is to modify m3dep so that the standard library directories > are searched even if they are not mentioned in file m3path so that > m3path isn't needed for small programs > I have experimented with this. The problem is that there comes a time when you DONT want to scan the standard libraries. So a getout option is essential. > The fact that m3dep uses file m3path in the directory in which it is > invoked makes it difficult to centralize the search paths. This could > be done with symbolic links to the top level directory but I would > prefer to have m3dep accept a -D option so that macros can be placed in > the global include file for GNU make. > In general using a local m3path seems the obviously correct behaviour. In the case of the specific problem of building a tree-structured distribution in one step, with a single set of search paths, centralisation seems convenient. In fact, an earlier version of m3dep for Modula-2 would take a top-level m3path, scan the world, and generate new makefiles everywhere. In general, I think it is dangerous to build too much policy into these kinds of tools. The fact that make has very little policy built-in is the major reason why it has been so successful. Mick ------------------------------------------------------------------------------ Date: Mon, 9 Jul 90 18:01:54 +0800 From: boykett@wacsvax.cs.uwa.OZ.AU (Tim Boykett) Subject: Symbolic Expression Thingys Does anyone know anything about the symbolic expressions stuff (Sx.def ??) that was part of Modula-2? It is metioned in the List.i3 interface which is direct from Modula-2 (+?). Does the equivalent exist anywhere, or has someone implemented something similar. I am looking for a module that will read in arithmetic expressions, and then perform evaluations easily. Yes I know it's easy to write your own, but I really dont like typing a whole lot :-) Thanks in anticipation Tim. ------------------------------------------------------------------------------ Date: Mon, 9 Jul 90 09:39:11 -0500 (CDT) From: Dick Orgass Subject: Re: m3 flags, M3DEFPATH and M3OBJPATH > Excerpts from mail: 6-Jul-90 Re: m3 flags, M3DEFPATH and.. Mick > Jordan@src.dec.com (2225) > In general, I think it is dangerous > to build too much policy into these kinds of tools. The fact that > make has very little policy built-in is the major reason why it has > been so successful. I strongly agree with Mick's statement! I think the problem is to identify a set of specifications for a tool that spans the range of problems that have been described (and possibly others) without setting policy. I know that I can't do that yet. Dick ------------------------------------------------------------------------------ Date: Mon, 09 Jul 90 10:54:02 PDT From: Eric Muller Subject: Re: Advice please. > I would therefore like to ask whether it is worth my while continuing to work > with version 1.4, or whether I should begin to work with version 1.5. In this > latter case, should I pull version 1.5 (beta) which I can get immediately, or > should I wait for the "real" 1.5? (I guess I am really asking when 1.5 is > expected to be released). I would advise that you use 1.5 for the port. The new organization makes it much easier. So far, gatekeeper.dec.com holds the "first" beta version. We do not have all the machines to which SRC Modula-3 has been ported, but people who have done the ports (David Goldberg, Ray Lischner, Richard Orgass and Piet van Oostrum) are busy checking the new version or the integration of their ports in the new version (thanks a lot to them). I am happy with the VAX and DECstation versions (they can be released). I will wait for the people checking the ports to tell me that they are happy with their versions to announce and distribute 1.5; may be they can tell the list what they think ? Eric Muller. ------------------------------------------------------------------------------ Date: Tue, 10 Jul 90 15:39:21 WST From: tim@madvax.oz.au (Tim Boykett) Subject: List.Assoc problem Is there a problem with List.Assoc ? It seems to not want to work with more than one thing in a list. I am doing List.List2(List.List2("blah", Integer.New(0)), List.List2("Blag", Integer.New(25))); and allocating it to a List.T variable. I can do an List.Assoc search for "blah", but not for "Blag"..it returns a (runtime) narrow fault, ie something is not of the appropriate type in XX := List.Assoc(state, "Blag"); where state is the List.T I stored the above construct in. Am I misunderstanding the use of ListN or Assoc? Is it a well-known bug? HELP! Thanks in advance Tim. ------------------------------------------------------------------------------ Date: Wed, 11 Jul 90 16:44:27 -0500 (CDT) From: Dick Orgass Subject: Version 1.5 beta on IBM Platforms At IBM Rochester, we've been working on the 1.5 beta version of SRC Modula-3 for the following three systems: IBMR2 AIX 3.1, RISC System/6000 IBMRT IBM/4.3 (aka AOS 4.3), IBM RT System AIX386 AIX 1.2, PS/2 Models 55SX, 70 and 80 Many thanks to Eric Muller of SRC for all of his advice and help. We're users of the IBM AIX products and are not involved in the development of these products. Therefore, these comments should not be interpreted as a commitment by IBM to support SRC Modula-3. We're using SRC Modula-3 and will report problems and fixes as they are made but can't promise to fix all bugs. I will be sending our most recent set of updates to Eric Muller at SRC tomorrow. The remainder of this note describes the status of our ports. In the comments that follow, when I say that the system is working I mean that the results obtained running our ports are the same as the results that Eric reports for the SRC host systems. There are bugs that Eric is fixing because they are not platform specific. IBMR2 The entire system appears to be working except for the following problems that I haven't been able to solve yet. These are clearly problems in the port and I will continue to investigate them. (1) An exception, Rd.Failure, is raised when attempting to read (an eof) from /dev/null. (2) Input piped to a program that reads from Stdio.stdin and output written to Stdio.stdout when it is piped to another program don't work correctly. Note that the X libraries shipped with AIX 3.1 are the X11r3 libraries though the server is X11r4 with extensions. This means that it is necessary to compile the X11r4 libraries to use the X interfaces and even to run the demo programs. The product C preprocessor appears to be a strict ANSI implementation and, as a result, doesn't work with imake. Both for X and for Modula-3, we've ported the Berkley C preprocessor and are using it with imake. Other alternatives are the version of cpp shipped in /usr/lpp/X11/Xamples/util/cpp or the GNU C preprocessor. IBMRT Michael Bauers of Broadway and Seymour, Inc is working on this port. Except for test p034, this port of the system works. The C code generated for this test case severely stresses the standard C compiler for the system, MetaWare's High C. It takes about 40 minutes to compile this one C file; far longer than any other file in the whole system. The resulting program doesn't work. The GNU C compiler emits an object file that clearly doesn't represent the source code and the C syntax is not accepted by the portable C compiler, pcc. Michael will pursue this problem. AIX386 We started on the port to this platform much later than the others because we've been trying to find a bug in thread context switches in version 1.4. We've been working with MetaWare's High C because the resulting object code is much smaller than the code emitted by /bin/cc. Ports done with /bin/cc have the same problems as ports done with /bin/cc. Both the C preprocessor shipped with the system and High C's internal preprocessor are strict ANSI preprocessors and don't work with imake. We're using a port of the Berkley C preprocessor; the GNU C preprocessor is another alternative. I spent two evenings working on this port and can report the following problems: (1) Thread context switch doesn't work. If the program is executed directly, there is a memory fault during thread context switch. When the same binary is executed from dbx, the program runs as expected. As a result, the following test cases (and other programs that use threads) fail: p007 p008 p031 p032 (2) Convert.ToFloat and Convert.ToLongFloat do not work correctly. This can be observed by looking at the appropriate parts of the output of test p040. Carl Gadow of Broadway and Seymour, Inc has been working on the thread context switch problem and is also working on some test cases for the operating system interfaces to provide a means of checking the translation of files from /usr/include into Modula-3 interfaces. We will contribute these test programs when they are completed. Carl will continue to work on the AIX/PS2 port with the objective of bringing it up to the level of the SRC system on other platforms. Dick ------------------------------------------------------------------------------ Date: Thu, 12 Jul 90 00:43:02 met From: Piet van Oostrum Subject: Re: Advice please. Hi Eric, On 09 Jul 90 you wrote: > I am happy with the VAX and DECstation versions (they can be > released). I will wait for the people checking the ports to tell me > that they are happy with their versions to announce and distribute > 1.5; may be they can tell the list what they think ? I am happy with the HP9000/300 version 1.5. I had the compiler compile itself from scratch and the ptests without problems Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Thu, 12 Jul 90 11:39:54 met From: Piet van Oostrum Subject: Re: Advice please. On 12 Jul 90 I wrote: > I am happy with the HP9000/300 version 1.5. I had the compiler compile > itself from scratch and the ptests without problems Well, I discovered another problem after that mail. The code for calculating record sizes and field alignments for packed fields in RecordType.m3 is totally inadequate for the HP-UX C compiler. The documentation on the way the C compiler does this was very hard to understand, but I think I know now what it means: Integers (longs) and other 4 byte quantities are aligned on 4 byte boundaries when they stand alone, and on 2 byte boundaries in records. I think the first fact is nowhere useful in the Modula-3 compiler. Record sizes are always rounded up to a multiple of 2 bytes. The code in Recordtype.Bind for packed fields assumes that a record consists of an integral number of integer fields and that bitfields must not cross the boundaries of these. Moreover, a record with some packed fields will tend to get a size that is a multiple of the integer size. Also the size that is used to calculate the width of the field is the default size of the representation type of the field (char/short/long), i.e. 8, 16 or 32 bits. It should use minSize rather than size of the type. On the HP-UX system the following algorithm is used: Bitfields are just packed next to each other, except when a bitfields would span more bytes than is natural for the type. I.e a long/int field should not span 5 bytes (which it could if it is more than 24 bits long). This sounds reasonable for a register based machine. A short field should not span 3 bytes, and a char field should not cross a byte boundary. If this occurs, the field will be aligned on the next alignment boundary (1 byte for char, 2 bytes for short/long). Example: struct test { int a:5; int b:28; int c:14; } x; main() { x.a = 1; x.b = -1; x.c = sizeof (x); } The record layout for x is: byte 0: 5 bits for a, 3 bits unoccupied. byte 1: filler byte 2,3,4: 24 bits for b byte 5: 4 bits for b, 4 bits for c byte 6: 8 bits for c byte 7: 2 bits for c, 6 filler. Size of the record = 8 bytes. (without field c it would have been 6 bytes). field b is aligned because otherwise it would span bytes 0-4. If c were defined as short it would be aligned on byte 6, because otherwise it would span 3 bytes. If there were additional fields, this could change the record size. (The strange thing here is that if you chose shorter types for you fields, the record may become larger!) The code in RecordType.Bind will calculate a size of 12 bytes, because it assumes the following record layout: byte 0: field a. byte 1-3: filler because there is not enough room in the longword for field b. byte 4-7: field b byte 8-9: field c byte 10-11: filler to make it an integral number of longwords. Modula-3 test program: MODULE Main; CONST C = 16384; TYPE Ta = [0..31]; Tb = [0..C*C-1]; Tc = [0..C-1]; Test = RECORD a: BITS 5 FOR Ta; b: BITS 28 FOR Tb; c: BITS 14 FOR Tc; END; VAR x: Test; BEGIN x.a := 1; x.b := 0; x.c := BYTESIZE (x); END Main. I don't think it will be possible to simply parametrize the algorithm for all systems. Maybe Target.m3 should have a procedure to do some work. By the way, the variable leftInThisUnit in RecordType.Bind is not initialized. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Thu, 12 Jul 90 14:01:59 PDT From: Eric Muller Subject: Re: Advice please. I believe that we can extend our algorithm to handle HP 9000/300 machines. >From the ANSI C standard, section 3.5.2.1: An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. ... The alignment of the addressable storage unit is unspecified. Our present algorithm assumes that a bit-field that does not fit is put into the next unit. If we allow for overlapping of adjacent units, we should get the desired effect. struct test { int a : 5; int b : 28; int c : 14; } We start we a, and allocate a storage unit (i.e. 4 bytes). We put a at the beginning and there are 27 bits remaining. That is not enough for b, so we allocate another 4 bytes. Currently we put b in that second unit; rather, we should let it overlap the two units. Respecting the alignment constraint of 2 bytes, we start b on byte 2 and there are 20 bits left in the second unit. Finally, there is enough space left for c in the second unit and we put it next to b. I think that the int/short difference does not matter, since we do not generate "short xx : n;" fields (this is not allowed in ANSI-C). I still have to check that the alignment parameters of Target.i3 are use only in the computation of record sizes, so that we can set it to 2 for integer on HP9000/300. Of course, we need to introduce a new parameter in Target.i3 to allow or disallow overlapping. By the way, did you try this example with gcc ? I have tried to use a similar algorithm (hence the names of the parameters that control record layout). > By the way, the variable leftInThisUnit in RecordType.Bind is not > initialized. leftInThisUnit is used in an iteration only when previousPacked is TRUE, which means that packed was TRUE at the previous iteration and leftInThisUnit was set. Eric Muller. ------------------------------------------------------------------------------ Date: Thu, 12 Jul 90 18:43:42 EDT From: emery@d74sun.mitre.org (David Emery) Subject: Re: Advice please. Incidentally, that "feature" of ANSI C just caused us a small nightmare tracking down a bug in the SAIC Ada binding to Xlib. The C struct looked something like char f; int i; and it's clearly compiler independent if the layout is 5 bytes or 8 bytes. The Ada code assumed it to be 8 bytes, and that was wrong. By the way, what does M3 do about the endian problems? If something is declared as a 6 bit quantity, is it stored |#|#|#|#|#|#| | | or | | |#|#|#|#|#|#| or is this machine dependent? Currently, in Ada this is machine dependent. If you get data where the layout is given in one of those pictures, then you have one Hell of a time writing a representation clause that covers this, without knowing the specific data layout of the machine. And, if the data is "little-endian", and your compiler/machine are "big-endian", you end up having to write a lot of messy code to accept the bit pattern and translate it into something usable on your machine. dave emery emery@aries.mitre.org ------------------------------------------------------------------------------ Date: Fri, 13 Jul 90 09:17:35 met From: Piet van Oostrum Subject: Re: Bit field alignment on HP-UX Path: piet Newsgroups: gnu.gcc.bug, comp.sys.hp From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: Bit field alignment on HP-UX References: <9007121103.AA19086@praxis.cs.ruu.nl> Reply-To: piet@cs.ruu.nl (Piet van Oostrum) In-reply-to: piet@cs.ruu.nl (Piet van Oostrum) Distribution: gnu Organization: Dept of Computer Science, Utrecht University, The Netherlands I am still trying to get the whole scoop on bit-field alignment in the HP-UX cc compiler on HP9000/300. I detected another case where the bit-field was aligned, which is actually more in line with what others do - if there were not a case that I don't understand - struct test { /* char p;*/ int a:14; int b:20; short c:5; } x; This case (with the char p commented out) aligns b on a 2-byte boundary, presumably because it would otherwise cross a 4-byte boundary, although 4-byte boundaries are not special in records. But if the char p is inserted, no padding is done, the field a doesn't even start on a 2-byte boundary. Now I don't understand what the underlying algorithm is. This might even be a bug. -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Fri, 13 Jul 90 16:05:59 PDT From: Eric Muller Subject: [fl@fred.tools.uucp (Frank Lancaster): Modula-3] The following message appeared on comp.lang.modula2. I am resending it on the list to make sure we don't miss any info on the subject. Eric Muller. ------- Forwarded Message Newsgroups: comp.lang.modula2 Subject: Modula-3 Message-ID: Date: 12 Jul 90 15:01:13 GMT Organization: TooLs GmbH, Bonn, W.-Germany With some minor changes I have ported the DEC Modula 3 compiler to a Sun 3, but there are still some problems with threads. Is anyone also working on this? Frank Lancaster, fl@tools.uucp ------- End of Forwarded Message ------------------------------------------------------------------------------ Date: Wed, 18 Jul 90 17:56:33 met From: Piet van Oostrum Subject: Re: Bit field alignment on HP-UX Path: piet Newsgroups: comp.sys.hp From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: Bit field alignment on HP-UX References: <3598@ruuinf.cs.ruu.nl> <7370172@hpfcso.HP.COM> Reply-To: piet@cs.ruu.nl (Piet van Oostrum) In-reply-to: mike@hpfcso.HP.COM (Mike McNelly) Organization: Dept of Computer Science, Utrecht University, The Netherlands In article <7370172@hpfcso.HP.COM>, mike@hpfcso (Mike McNelly) writes: | |The best and most current source of information about bitfields on |Series 300 is the HP-UX Portability Guide, HP Part Number 98794-90046. |The information below was an original source for that discussion |although I believe that signed bitfields are now supported. | |Mike McNelly |mike%hpfcla@hplabs.hp.com |======================================================================= | |Bitfields are assigned left to right and are unsigned regardless of the |declared type. They are aligned so that they do not violate the |alignment restriction of the declared type. Consequently some padding |within the structure may be required. | |For example, | | struct foo | { | unsigned int a:3, b:3, c:3, d:3; | unsigned int remainder:20; | }; | |For the above struct, sizeof(struct foo) would return 4 (bytes) because |none of bitfields straddle a 4 byte boundary. On the other hand, the |following struct declaration will have a larger size. | | struct foo2 | { | unsigned char a:3, b:3, c:3, d:3; | unsigned int remainder:20; | }; | |In this struct declaration the assignment of data space for c must be |aligned so as not to violate a byte boundary, which is the normal |alignment of unsigned char. Consequently two undeclared bits of padding |are added by the compiler so that c is aligned on a byte boundary. |sizeof(struct foo2) therefore returns 6 (bytes). | |Bitfields on Series 200, 300, and 500 machines cannot exceed the size of |the declared type in length. Therefore the largest possible bitfield is |32 bits. All scalar types are permissable to declare bitfields, |including enums. However, they are inherently unsigned. I had read this passage several times, and I have tried to attach some kind of semantics to it. I think the wording is highly ambiguous, but I thik I have grasped its meaning now. Let me try to formulate the underlying algorithm. 1. A halfword is a sequence of two bytes starting at an even address, a longword is a sequence of four bytes starting at any EVEN address. (these are the words as I am going to use them below. 2. A bitfield that is declared as a char must fit into a byte, a field that is declared as a short must fit into a halfword (as defined above), and a field that is declared as an int or long must fit into a longword. If the field does not fit, it is aligned on the next boundary (1 byte for char, 2 bytes for short/int/long). The following examples illustrate this: I. struct test { int a:14; int b:20; int c:5; } x; b will be aligned because otherwise it would occupy (part of) bytes 1,2,3,4, which is one byte more than the longword starting at byte 0. II. struct test { char p; int a:14; int b:20; int c:5; } x; Now NO PADDING is required because a fits in the logword starting at byte 0 and b spans byte 2,3,4,5 which fits into the longword starting at byte 2. III. struct test { char p; short a:14; int b:20; int c:5; } x; In this case a is defined as short so it has to fit into a halfword. It doesn't fit into the halfword at byte 0, so it is aligned on byte 2. -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: 23 Jul 1990 21:51:22 EST From: KEN@DOM.DOM.UAB.EDU Subject: Modula-3 for VMS Could someone please tell me the status of the port of Modula-3 to VMS. Thanks in advance. Ken Beaudrie Internet: ken@dom.dom.uab.edu Sr. Systems Analyst ( 138.26.46.1 ) Dept. of Medicine Computing Center BITNET: BEAUDRIE@UABCMC Univ. of Alabama at Birmingham ------------------------------------------------------------------------------ Date: Tue, 24 Jul 90 14:24:59 PDT From: Eric Muller Subject: SRC Modula-3 1.5 available SRC Modula-3 ------------ A new release, version 1.5, of the SRC Modula-3 compiler and runtime are available now. This is the third public release of SRC Modula-3. The system was developed at the DEC Systems Research Center. It is being distributed in source form (mostly Modula-3) and is available for public ftp. You must have a C compiler to build and install the system. The primary changes since version 1.4 are: - many bugs are fixed - the libraries have been reorganized and extended - demos and games have been added - the system was ported to: Apollo DN4500 running Domain/OS, IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, HP 9000/300 running HP-UX 8.0 in addition to the previous ports: VAX running Ultrix 3.1 DECstation 3100 and 5100 running Ultrix 3.1 SPARCstation running SunOS 4.0.3 - the installation on multiple platforms is easier - ports are easier SRC Modula-3 is available without signing any license agreements. If you chose to sign the commercial license, you will be able to use SRC Modula-3 commercially. Modula-3 is a new language. The goals of its design are best encapsulated in the preface to the Modula-3 Report [1]: The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the garbage collector and the very lowest levels of the thread implementation, the entire system is written in Modula-3. The system is available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The SRC Modula-3 files are in '/pub/DEC/Modula-3'. Those files include: m3-1.5.tar.Z the system m3-1.5.tar.Z-{01,...,12} same, in pieces Report.ps the revised language report Report{1,2,3}.ps same, in pieces Release-1.5.ps the user manual (PostScript) m3-mail..Z archive of mail sent to m3@src.dec.com The compressed tar files are about 6.0Mbytes after compression. The entire system requires about 35Mbytes of disk space to build and install. We are maintaining a mailing list of those interesting in SRC Modula-3. The list is 'm3@src.dec.com'. To be added to the list send a message to 'm3-request@src.dec.com'. We may also be reached at: Systems Research Center 130 Lytton Avenue Palo Alto, CA 94301 Enjoy, Bill Kalsow and Eric Muller References ---------- [1] The Modula-3 Report (Revised), L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89. VAX, DECstation and ULTRIX are registered trademarks of Digital Equipment Corporation. Unix is a registered trademark of AT&T Corporation. SPARC and SunOS are trademarks of Sun MicroSystems. Apollo and Domain/OS are trademarks of Apollo. IBM and AIX are registered trademarks of International Business Machines Corporation. RT and PS/2 are trademarks of International Business Machines Corporation. HP, HP9000 and HP9000/300 are trademarks of Hewlett-Packard Company. HP-UX is Hewlett-Packard's implementation of the Unix operating system. PostScript is a registered trademark of Adobe Systems Incorporated. ------------------------------------------------------------------------------ Date: Tue, 24 Jul 90 16:59:54 -0700 From: Wendell Craig Baker Subject: On the use of fullpaths in symbolic links I am currently building the m3 1.5 release and it is going quite well. There has definitely been alot of work done to get the system to come up trouble-free. There are a few things however that might make the system easier to pull up and maintain at the user's site. I notice that fullpaths are used in the build procedure. The following is a portion of the ``make.out'' indicating the fullpaths created: ... deleted ... --- driver starting on Tue Jul 24 16:25:10 PDT 1990 --- driver done on Tue Jul 24 16:25:11 PDT 1990 --- loader starting on Tue Jul 24 16:25:12 PDT 1990 --- loader done on Tue Jul 24 16:25:13 PDT 1990 --- compiler starting on Tue Jul 24 16:25:14 PDT 1990 ------ builtinOps starting on Tue Jul 24 16:25:16 PDT 1990 mkdir ../Interfaces ln -s `pwd`/Abs.i3 ../Interfaces ln -s `pwd`/Adr.i3 ../Interfaces ln -s `pwd`/AdrSize.i3 ../Interfaces ln -s `pwd`/BitSize.i3 ../Interfaces ln -s `pwd`/ByteSize.i3 ../Interfaces ln -s `pwd`/Ceiling.i3 ../Interfaces ... deleted ... While this is currently working just fine, it has been the experience in the past that fullpaths used symbolic links (especially in a multi-server NFS environment) are rarely robust for very long. Further, the ``breakage'' is rarely obvious and almost never is indicated by an error message such as ``the fullpath in the symbolic link does not exist''. The danger is that the symbolic links require that the Modula3 installation be fixed in a specific path. Should it ever be necessary to change the directory in which Modula3 is installed (due to a disk reorganization, host failure, a whim, or other Act of God), then the whole of the Modula3 release will have to be re-created. Maybe in the future for release 1.6 these fullpaths could be converted over to relative paths (much like the ../../../. symbolic links to the .ROOT directory). Thank you, W. ------------------------------------------------------------------------------ Date: Tue, 24 Jul 90 22:19:51 PDT From: Eric Muller Subject: Re: On the use of fullpaths in symbolic links > I notice that fullpaths are used in the build procedure. In some earlier version, we had relative names by a ln of the form: (cd ../Interfaces; ln -s ../*/Abs.i3 .) But this is a bit ugly, in part because it requires Abs.i3 to be unique among all the subdirectories of .. Also, I seem to remember there was a problem on some machines. I think I will change that to: PWD=`pwd`; REL=`basename $PWD`; ln -s ../$REL/Abs.i3 ../Interfaces for a future release. Please, if anybody sees a problem with that, or a better solution, let me know. > While this is currently working just fine, it has been the > experience in the past that fullpaths used symbolic links (especially in > a multi-server NFS environment) are rarely robust for very long. True, but this is due in good part to poor installation of the file systems. Let's face it, it is difficult to have good multi-server NFS organization, but it is possible. Of course, saying it is somebody else problem does not help. Eric Muller. ------------------------------------------------------------------------------ Date: Tue, 24 Jul 90 22:31:50 PDT From: Eric Muller Subject: bad addresses in the mailing list >From time to time, we get addresses in the m3 mailing list that do not work. Unfortunately, we cannot invest time in tracking down the problems (the list is too large). We do remove such addresses to minimize the inconvenience to posters; we hate to lose readership (although we are not paid by the number of subscribers...) but we have little choice. If you are on the list and don't see any traffic for some time, it may be case that we removed you from the list. Please excuse us, and send a mail to m3-request (NOT m3) if you suspect this is the case. We will double check the addresses at that point. Thanks for your patience, Eric Muller. ------------------------------------------------------------------------------ Date: Tue, 24 Jul 90 22:42:26 PDT From: Eric Muller Subject: Re: List.Assoc problem > Is there a problem with List.Assoc ? > It seems to not want to work with more than one thing > in a list. I am doing > List.List2(List.List2("blah", Integer.New(0)), > List.List2("Blag", Integer.New(25))); > and allocating it to a List.T variable. > I can do an List.Assoc search for "blah", but > not for "Blag"..it returns a (runtime) narrow > fault, ie something is not of the appropriate > type in > XX := List.Assoc(state, "Blag"); > where state is the List.T I stored the above > construct in. Am I misunderstanding the use > of ListN or Assoc? Is it a well-known bug? Sorry for not answering your message earlier. This seems to be fixed in 1.5 (which is now available; what a coincidence !). Eric Muller. ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 10:54:42 met From: Piet van Oostrum Subject: SRC Modula-3 1.5 available > HP 9000/300 running HP-UX 8.0 ^^^ This should be 7.0 Piet van Oostrum ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 17:09:12 GMT From: karl@ofssrv.syssup.tds.philips.nl (Karl Lovink) Subject: maillist Modula-3 Could you please add my name to the maillist about Modula3 ( ) Karl Lovink Philips Information Systems, Netherlands } @ @ { Department: Systems Support Optical Filing -- |___| -- UUCP: uunet!mcsun!philapd!idcapd!ofssrv!karl _/ \_ NET : karl@ofssrv.syssup.tds.philips.nl ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 15:07:03 met From: Piet van Oostrum Subject: Spelling In dist-1.5/doc/intro.tex: \cont{Piet van Oostrum} (Utretch University) ported the system to the ||| \cont{Piet van Oostrum} (Utrecht University) ported the system to the Now try to guess the local pronunciation :=). Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 17:37:04 met From: Piet van Oostrum Subject: Installation problems on HP-UX 1. The toplevel makefile is missing a line SHELL=/bin/sh 2. sed on SYSV systems does print substituted lines only with -n. Besides that the parentheses in the command for imake in the makefile are superfluous, so I changed this to: imake: FRC @cd util; \ cpp=`cat config | sed -n -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -n -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ sed -e s+M3_CPP+$$cpp+ imake.c > imake.foo.c; \ $$cc -o imake imake.foo.c; \ /bin/rm -f imake.foo.c 3. The file util/install.HP300 should have mode rx. 4. config.dist-HP300 should have CLINKFILES = -lm -lBSD Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 17:42:47 met From: Piet van Oostrum Subject: Installation doc. The manual says on page 6, item 9: $ cat m3-1.5.tar.Z-* m3-1.5.tar.Z which obviously should be: $ cat m3-1.5.tar.Z-* > m3-1.5.tar.Z On page 7, item 4, the $ prompt is a bit mis-aligned. On page 8 and 25 there are a couple of others too. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 09:55:08 PDT From: eldred@de_csi.Jpl.Nasa.Gov (Dan Eldred) Subject: Please put me on Modula-3 mailing list Question: what is the smallest m3 system which is functional? I don't have 35 Mbytes to to spare for m3 on a permanent basis. Thanks-- ------------------------------------------------------------------------- Dan Eldred eldred@csi.jpl.nasa.gov ------------------------------------------------------------------------- ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 13:42:42 -0400 From: George M. Jones Subject: SRC Modula-3 1.5 available I have FTPed the 1.5 files and made them available for anonymous UUCP on osu-cis. The following is an extract from our general instructions about how to pick up software from osu-cis ==============================GNU.how-to-get============================== This file (osu-cis!~/GNU.how-to-get) describes how to get the following software from osu-cis via semi-anonymous UUCP: C++ Test Suite Compress Deliver 2.0 GNU Binary Utilities GNU Assembler GNU Awk GNU Bash GNU Bison GNU C++ Compiler GNU C++ Library GNU C Compiler GNU Chess GNU COFF hacks GNU CPIO GNU DBM GNU Debugger GNU Diff GNU Emacs GNU Emacs Ada support GNU Emacs Franz interface GNU Emacs Lisp Manual GNU File Utils GNU Find GNU Finger GNU Go GNU Gperf & Cperf GNU Grep GNU Indent GNU Lex GNU Make GNU Pins & Art GNU Plot & Plot2PS GNU Roff GNU Sed GNU Tar GNUS Ghostscript Gnews Ispell KA9Q Kermit M3 MIT C Scheme Mg2a NNTP News Oops PCRRN Patch Pathalias Protoize Proxy ARP RCS RFCs & IDEAS RN SB Prolog STDWIN Sendmail Smail Smalltalk Tcsh VM There's a lot of other available miscellany that isn't explicitly listed here. You can find out about it in the file osu-cis!~/ls-lR.Z The Computer and Information Science Department of the Ohio State University provides Free Software Foundation GNU products (and others) via UUCP only as a redistribution service. Anything found here is only and exactly as it would be found on the indicated Internet hosts, were one to acquire it via anonymous FTP (like we did); or else saved it as it flowed past on the Usenet source distribution newsgroups. OSU CIS takes no responsibility for the contents of any of the distributions described in this message. See the Distribution document (emacs/etc/DISTRIB when you unpack and build Emacs) and the GNU Emacs General Public License (emacs/etc/COPYING, similarly). Much of the GNU software is in beta-test. For a list of the current statuses (stati?), ask gnu@prep.ai.mit.edu for a copy of the latest FSF order form. How to reach osu-cis via uucp =============================== Here is a set of L.sys or Systems file lines suitable for osu-cis: # # Direct Trailblazer # osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon # # Direct V.32 (MNP 4) # dead, dead, dead...sigh. # #osu-cis Any ACU 9600 1-614-292-1153 in:--in:--in: Uanon # # Micom port selector, at 1200, 2400, or 9600 bps. # Replace ##'s below with 12, 24, or 96 (both speed and phone number). # osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r \d\r in:--in:--in: Uanon Modify as appropriate for your site, of course, to deal with your local telephone system. There are no limitations concerning the hours of the day you may call. We are deeply grateful to Philips Components of Eindhoven, the Netherlands for the donation of a Trailblazer Plus and a Codex 2264 for use by the community at large. Where the files are =================== Most items exist on osu-cis for distribution purposes in compressed tar form, exactly what you find on the indicated hosts in the specified origin files. Most items are cut into pieces for the sake of uucp sanity. This separation helps if your uucp session fails midway through a conversation; you need restart only with the part that failed, rather than the whole beast. The pieces are typically named with a root word, followed by letter pairs like "aa" and "bj," meaning that the pieces are all named with the root word, followed by a dash and the suffixes indicated, using the letters inclusive between the two limits. All pieces but the last are 100,000 bytes long, and the fragmentary last piece has some smaller size. The instruction listings below are alphabetized as in the summary block above. . . . m3 - DEC/Olivetti Modula 3 Compiler -- Source is gatkeeper.dec.com. Root is ~/m3/. Files are: README 3970 bytes m3-1.5.tar.Z the system 5845892 bytes m3-1.5.tar.Z-{01,...,12} same, in pieces 524288 bytes each (part 1-11) 78724 bytes (part 12) Report.ps the revised language report 258305 bytes Report{1,2,3}.ps same, in pieces 103558 bytes (part 1) 109352 bytes (part 2) 105183 bytes (part 3) Release-1.5.ps the user manual (PostScript) 237915 bytes README is the message that was posted by DEC announcing the 1.5 release. It describes briefly what Modula 3 is and the particular files are. . . . ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 13:06:12 PDT From: Eric Muller Subject: Re: Installation doc. Thanks for noticing all these errors. I am very sorry about the mispelling of Utrecht. Eric Muller. ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 13:10:23 PDT From: Eric Muller Subject: Re: smallest system > Question: what is the smallest m3 system which is functional? I > don't have 35 Mbytes to to spare for m3 on a permanent basis. Thanks-- All the files that are needed for normal operation are installed. This means that you can delete the distribution. On a VAX, the installed files occupy 4941 Kb. On a DECstation, 7293 Kb. Eric Muller. ------------------------------------------------------------------------------ Date: 25 Jul 1990 1314-PDT (Wednesday) From: Subject: Unimplemented procedures. "A program is a collection of modules in which no procedure is multiply defined." So it is ok for a program to contain unimplemented procedures. However, the effect of doing so in the SRC system is to get an undefined symbol from 'ld'. In the Olivetti system the pre-linker warned you about unimplemented procedures and then generated a dummy procedure which raised an exception if called. Any chance of something similar? Or should the language report be tightened up to forbid this situation? Mick ------------------------------------------------------------------------------ Date: Wed, 25 Jul 90 15:41:10 PDT From: Eric Muller Subject: Re: Unimplemented procedures. Mick Jordan ask: > So it is ok for a program to contain unimplemented procedures. > However, the effect of doing so in the SRC system is to get an > undefined symbol from 'ld'. In the Olivetti system the pre-linker > warned you about unimplemented procedures and then generated a dummy > procedure which raised an exception if called. Any chance of something > similar? I don't think this is a problem that should be handled at the Modula-3 level. It would be much better to have a generic linker do this kind of work; indeed, if you have such a linker, nothing prevents you of using it for linking Modula-3 programs. Eric Muller. ------------------------------------------------------------------------------ Date: Thu, 26 Jul 90 10:16:13 met From: Piet van Oostrum Subject: Please put me on Modula-3 mailing list Hi Dan, On 25 Jul 90 you wrote: > Question: what is the smallest m3 system which is functional? I > don't have 35 Mbytes to to spare for m3 on a permanent basis. Thanks-- On HP-UX (HP9000/300) it is 4 MB. Piet van Oostrum ------------------------------------------------------------------------------ Date: Thu, 26 Jul 90 11:25:07 met From: Piet van Oostrum Subject: A few morepatches for m3 1.5 *** M3Runtime.c.~1~ Mon Jul 23 20:53:23 1990 --- M3Runtime.c Thu Jul 26 10:17:57 1990 *************** *** 59,67 **** #if defined (HP300) #include #endif - #include #include #include --- 59,68 ---- #if defined (HP300) #include + #else + #include #endif #include #include The intermediate compiler m3.local (and I guess also m3.cross) do miss the needed -lBSD on the link phase on HP-UX. This can be corrected (valid on all systems by patching system/driver/Imakefile: *** Imakefile.~1~ Mon Jul 23 20:53:18 1990 --- Imakefile Thu Jul 26 11:00:15 1990 *************** *** 16,22 **** -e 's+PASS2+.ROOT/system/loader/m3ld+' \ -e 's+DEFPATH+-D -D.ROOT/system/corelib/Interfaces -D.+' \ -e 's+LIBPATH+-L.ROOT/system/corelib+' \ ! -e 's+LINKFILES+.ROOT/system/runtime/m3run.o -lm3core -lm+' \ -e 's+LINKCOVER+.ROOT/tools/coverage/report_coverage.o+' \ -e 's+INCLDIR+.ROOT/system/runtime+' \ -e 's+LD_WANTS_SPACE_AFTER_L+$(LD_WANTS_SPACE_AFTER_L)+' \ --- 16,22 ---- -e 's+PASS2+.ROOT/system/loader/m3ld+' \ -e 's+DEFPATH+-D -D.ROOT/system/corelib/Interfaces -D.+' \ -e 's+LIBPATH+-L.ROOT/system/corelib+' \ ! -e 's+LINKFILES+.ROOT/system/runtime/m3run.o -lm3core $(CLINKFILES) +' \ -e 's+LINKCOVER+.ROOT/tools/coverage/report_coverage.o+' \ -e 's+INCLDIR+.ROOT/system/runtime+' \ -e 's+LD_WANTS_SPACE_AFTER_L+$(LD_WANTS_SPACE_AFTER_L)+' \ *************** *** 30,36 **** -e 's+PASS2+.ROOT/.cross/loader/m3ld+' \ -e 's+DEFPATH+-D -D.ROOT/.cross/corelib/Interfaces -D.+' \ -e 's+LIBPATH+-L.ROOT/system/corelib+' \ ! -e 's+LINKFILES+.ROOT/.cross/runtime/m3run.o -lm3core -lm+' \ -e 's+LINKCOVER+.ROOT/tools/coverage/report_coverage.o+' \ -e 's+INCLDIR+.ROOT/.cross/runtime+' \ -e 's+LD_WANTS_SPACE_AFTER_L+$(LD_WANTS_SPACE_AFTER_L)+' \ --- 30,36 ---- -e 's+PASS2+.ROOT/.cross/loader/m3ld+' \ -e 's+DEFPATH+-D -D.ROOT/.cross/corelib/Interfaces -D.+' \ -e 's+LIBPATH+-L.ROOT/system/corelib+' \ ! -e 's+LINKFILES+.ROOT/system/runtime/m3run.o -lm3core $(CLINKFILES) +' \ -e 's+LINKCOVER+.ROOT/tools/coverage/report_coverage.o+' \ -e 's+INCLDIR+.ROOT/.cross/runtime+' \ -e 's+LD_WANTS_SPACE_AFTER_L+$(LD_WANTS_SPACE_AFTER_L)+' \ util/clone.c needs a few adaptions: *** clone.c.~1~ Mon Jul 23 20:51:03 1990 --- clone.c Thu Jul 26 11:14:05 1990 *************** *** 12,18 **** #include #include ! #if defined (AIX386) #define gd_name d_name #endif --- 12,18 ---- #include #include ! #if defined (AIX386) | defined (HP300) #define gd_name d_name #endif *************** *** 204,210 **** fn (current_dir->path, file->gd_name, current_dir->depth + 1, &statbuf); }}} ! #if defined(IBMRT) closedir (dir);} /* Doesn't return anything on IBM/4.3 */ #else if (closedir (dir) != NULL) { --- 204,210 ---- fn (current_dir->path, file->gd_name, current_dir->depth + 1, &statbuf); }}} ! #if defined(IBMRT) | defined (HP300) closedir (dir);} /* Doesn't return anything on IBM/4.3 */ #else if (closedir (dir) != NULL) { Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete') ------------------------------------------------------------------------------ Date: Fri, 27 Jul 90 00:03:37 met From: Piet van Oostrum Subject: bug in 1.5 Analyze_coverage has a slight misspelling. Not that it helps much to correct it because install_coverage has not been ported, but at least it helps to complete the make. *** analyze_coverage.c.~1~ Mon Jul 23 20:51:39 1990 --- analyze_coverage.c Thu Jul 26 23:15:13 1990 *************** *** 11,17 **** #include #include #if defined (HP300) ! #include #endif #include --- 11,17 ---- #include #include #if defined (HP300) ! #include #endif #include ------------------------------------------------------------------------------ Date: Thu, 26 Jul 90 15:53:19 PDT From: Eric Muller Subject: Re: bug in 1.5 > Analyze_coverage has a slight misspelling. Not that it helps much to > correct it because install_coverage has not been ported, but at least it > helps to complete the make. Thanks for this correction. Note that the -Z option of m3(1) does not use install_coverage; the compiler generate the appropriate C code. In other words, you don't need install_coverage for Modula-3 programs. Eric Muller. ------------------------------------------------------------------------------ Date: 27 Jul 90 16:04:24 PDT (Friday) From: "James_Plank.PARC"@Xerox.COM Subject: Version stamp bug The following four files gave me a version stamp error when compiled with the m3-1.5 compiler on a SPARC. (I got the same error with the 1.5-beta compiler as well) In A.i3: INTERFACE A; TYPE AT2 = BRANDED OBJECT i1: INTEGER; END; TYPE AT3 = BRANDED OBJECT i1: INTEGER; END; END A. In B.i3: INTERFACE B; TYPE BT3 = BRANDED OBJECT i1: INTEGER; END; TYPE BT2 = BRANDED OBJECT i1: INTEGER; END; END B. In A.m3: MODULE A EXPORTS A, B; BEGIN END A. and in Main.m3: MODULE Main; IMPORT A, B; BEGIN END Main. When I compile them all together, I get the following: %m3 -g A.i3 B.i3 A.m3 Main.m3 ld: Undefined symbol _VS_B__BT2__2a5dfe062d76bf04 _VS_B__BT3__a5c1dbc638b36289 ------------------------------------------------------------------------------ Date: 30 Jul 90 17:13:04 PDT (Monday) From: "James_Plank.PARC"@Xerox.COM Subject: M3 1.5 Installation on the SPARC These are the bug/idiosyncracies which were found when installing m3-1.5 on the SPARCs here at Xerox. If anyone's interested, I've got a shell script which will automatically fix the bugs as well, but I won't clog the list by including it here. Jim Plank plank.parc@xerox.com **BUGS** 1. In util/config, change PREFIX to some new path name -- such as /usr/m3-1.5. Also in util/config, change: LIBX11 = /usr/local/lib/libX11.a LIBXT = /usr/local/lib/libXt.a LIBXMU = /usr/local/lib/libXmu.a LIBXEXT = /usr/local/lib/libXext.a LIBXAW = /usr/local/lib/libXaw.a to LIBX11 = /import/X11R4/usr/lib/libX11.a LIBXT = /import/X11R4/usr/lib/libXt.a LIBXMU = /import/X11R4/usr/lib/libXmu.a LIBXEXT = /import/X11R4/usr/lib/libXext.a LIBXAW = /import/X11R4/usr/lib/libXaw.a and DVIPS = dvips to DVIPS = dv2ips as well as (see bug #5 for further details): UNIX_LIB = ultrix-3.1 to UNIX_LIB = ultrix-3-1 2. Change the two sed scripts on lines 70 and 71 in ./makefile from: cpp=`cat config | sed -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ to cpp=`cat config | sed -n -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -n -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ 3. In doc/Imakefile, change: f.ps: f.dvi ; -$(DVIPS) -o f.ps f.dvi @@\ to: f.ps: f.dvi ; -$(DVIPS) f.dvi > f.ps @@\ and make sure that /import/bin is in your PATH. 4. For help in debugging (if any is needed), it's nice to keep the sources of the compilers around. Thus, in system/driver/Imakefile, comment out the following three lines (lines 25, 39, and 53): -/bin/rm -f m3.local.c -/bin/rm -f m3.cross.c -/bin/rm -f m3.public.c Remember that Imakefiles are commented out with /* */. 4a. Also, keep m3ld.local.c around -- comment line 13 of system/loader/Imakefile 5. ld on this system doesn't like to load libraries which have extraneous dots in their file names -- it tries to interpret them as version numbers. In any case, it can't find libm3ultrix-3.1.a; thus, change the name of all the ultrix files to *ultrix-3-1*, using 5a-5c. To be really robust, all the libraries with dots (like aix-3.1, etc.) should be changed (./convert actually does this), but since we only use the ultrix one, the rest can be ignored. 5a: In libs/Imakefile, change: subdir (ultrix-3.1) to subdir (ultrix-3-1) 5b: Rename libs/ultrix-3.1 to libs/ultrix-3-1. 5c: In libs/litrix-3-1, change: LIB = ultrix-3.1 to LIB = ultrix-3-1 ------------------------------------------------------------------------------ Date: Tue, 31 Jul 90 09:53:40 BST From: James G Smith Are there any holders of the 1.5 release of the SRC Modula-3 in the United Kingdom? I am unable to get access to anonymous ftp, and would be grateful if someone could write a tape for me. I will provide the tape and reimburse all mailing costs if this is necessary. Thanks in advance, Jamie ------------------------------------------------------------------------------ Date: 31 Jul 90 17:54:54 +0100 (Tuesday) From: Peter Robinson Subject: Re: Seeking version 1.5 I guess that we are probably the closest site to you running version 1.5 of SRC Modula-3 (200 metres away?). Why not call round. - Peter Robinson. ------------------------------------------------------------------------------ Date: Tue, 31 Jul 90 13:22:51 EDT From: fkz@cs.brown.edu (Kenneth Zadeck) Subject: Small problem with the M3 grammar: In the production for Declaration there is the line: | REVEAL { TypeID ( "=" | "<:" ) Type ";" } What is a TypeID? Is it supposed to be TypeName? Kenny Zadeck ------------------------------------------------------------------------------ Date: Tue, 31 Jul 90 10:39:02 PDT From: amdcad!sun0!mri!woolsey (Jeff Woolsey) Subject: M2 libraries Are there any Modula-3 implementations out there of the Modula-2 libraries from Wirth's books? At the moment I'm most interested in InOut and FileSystem. -- Jeff Woolsey Microtec Research, Inc. .!amdcad!sun0!woolsey +1 408 980 1300 x585 ------------------------------------------------------------------------------