jack@cs.glasgow.ac.uk (Mr Jack Campin) (07/19/88)
I posted a request for information about Modula-2 compilers for the Sun 3. Here are the requirements I specified: > It must: > - generate native code > - be stable (not being beta-tested on paying customers) > - be good at supporting low-level gunge (inc. cross-calling to > assembler and C) > - have good and well-documented libraries > - specify its semantics a LOT better than Wirth's manuals do. > Price is not particularly important, quality IS. The last ounce of > efficiency in code generation is nowhere near as important as the > absence of semantic boobytraps. I have had four suggestions so far, two from the net: * One person liked Sun's own compiler a LOT, saying their support was excellent, it was a mature and pretty bugfree product, it did cross-calling, had fantastic libraries, had a makefile generator, and had built-in dbxtool support. It has extensions beyond Wirth, which can safely be ignored. The person who wrote it is now at Oregon Software (see below). * Albert Meier recommended a German compiler that seems to have vanished from the marketplace: > Yes such a compiler exists. It is called MOCKA and was developed by > Franz Engelmann at GMD. GMD started marketing at a very low level and > sold the whole know-how (including Franz Engelmann, who is member of > the ISO Modula-2 working group) to another company in Germany. [note on why you can't get it now...] > Compared to the Sun M2 compiler from Sun themselves MOCKA is/was > about 3-4 times faster compiling and about 30% in execution time. The > comparison was made in December 1987. The look and feel is also much > better. Let's hope that MOCKA still will come. > aplusl@ifi.ethz.(ch/UUCP), ...mcvax!cernvax!ethz!aplusl I also got two replies by paper mail from companies that monitor this newsgroup. Both of them claim very high conformity to standards (they are both involved in ISO standardization committees), well-optimized native code generation including 68881 support, cross-calling to C and assembler, and make facilities. Both are available for other processors and operating systems. ACE claims to have very thorough documentation and includes library sources; Oregon to have a nice debugger and source code version control. * ACE Associated Computer Experts bv Van Eeghestraat 100, 1071 GL Amsterdam, Netherlands, +31 20 646416 They took the trouble to send me a personal reply, written by someone who understood what I was talking about. * Oregon Software 6915 SW Macadam Avenue, Portland, OR 97219-2397, USA, 910 464 4779 Their system is not yet released (due August 1988). But it shares many components with their existing Pascal/2 system, so it isn't likely to be vapourware. They contacted me by phone; again, the sales person knew his stuff. (But whoever monitors the net doesn't get the details through to the sales people in one piece!) We haven't made a decision yet (even on whether we want to use Modula at all). ACE and Oregon both look very attractive, maybe with ACE having the edge. (It looks from ACE's description that their compiler and UKC's `ups', the best debugger on the planet, could be made to interwork with a bit of hacking. If someone were to make that happen I might even try to *like* Modula). Comments? One point that mystified me is why Modula should need special make and version control gubbins, as Sun, ACE and Oregon all provide. Why can't the general purpose ones - SCCS, nmake, and friends - hack it? -- ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@cs.glasgow.uucp JANET:jack@uk.ac.glasgow.cs useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND work 041 339 8855 x 6045; home 041 556 1878
konijn@ace.UUCP (Erik van Konijnenburg) (07/22/88)
Hi. In his summary of responses, <jack@cs.glascow.ac.uk> writes: > One point that mystified me is why Modula should need special make and version > control gubbins, as Sun, ACE and Oregon all provide. Why can't the general > purpose ones - SCCS, nmake, and friends - hack it? The general purpose ones can, but they need some help. As an example, you would not want to have to edit your makefile every time you change an import dependency between modules, so we added a tool that automatically adds the import dependencies to an ordinary makefile. In the area of source code version control, SCCS does just fine as the bottom layer of CADESE, an integrated source and distribution management system. There is nothing language specific here, so we don't package CADESE with the Modula-2 compiler. Source code version control does not protect you from accidentally using the compiled version of an implementation module in combination with a definition module that has been radically altered after the implementation was compiled, so it is up to the Modula-2 compiler to give a warning if this happens. To do this, you need a time stamp in the compiled objects, but that is all a Modula-2 compiler needs to know about version control. Erik. --------- Erik van Konijnenburg email: <konijn@ace.nl> ACE Associated Computer Experts bv ...!mcvax!ace!konijn van Eeghenstraat 100 tel: +31 20 6646416 1071 GL Amsterdam fax: +31 20 750389 The Netherlands tx: 11702 (ace nl)
wyle@solaris.UUCP (Mitchell Wyle) (07/25/88)
In article <1501@crete.cs.glasgow.ac.uk> jack@cs.glasgow.ac.uk (Mr Jack Campin) writes: > >I posted a request for information about Modula-2 compilers for the Sun 3. > * One person liked Sun's own compiler a LOT, saying their support was That person was I. > excellent, it was a mature and pretty bugfree product, it did > cross-calling, had fantastic libraries, had a makefile generator, > and had built-in dbxtool support. It has extensions beyond Wirth, > which can safely be ignored. The person who wrote it is now at > Oregon Software (see below). The person who wrote the compiler is now at Oregon. The person who wrote the review is at the ETH. The beyond-Wirth extensions might be useful if your project wants to use special features of Sun OS/hardware. >We haven't made a decision yet (even on whether we want to use Modula at all). If I were developing a serious product on Suns, I'd probably stick to C; teaching in an environment where Modula-2 is known requires a M2 compiler. Sun's is very good for the job. (I won't expound on that point in this paragraph. ;-) >ACE and Oregon both look very attractive, maybe with ACE having the edge. (It >looks from ACE's description that their compiler and UKC's `ups', the best >debugger on the planet, could be made to interwork with a bit of hacking. >If someone were to make that happen I might even try to *like* Modula). dbxtool is ok as well, especially with mouse/graphical/event-driven code. >One point that mystified me is why Modula should need special make and version >control gubbins, as Sun, ACE and Oregon all provide. Why can't the general >purpose ones - SCCS, nmake, and friends - hack it? I was probably not clear as to this point. There are no "special gubbins." Sun's compiler has support for all of the general-purpose tools you mention, including SCCS, nmake, makemake, and interfaces to C, fortran, pascal, etc. The manual explains these and many other topics in a clear, concise manner. I learned sccs from the m2 manual. The make-file generator m2mg is very helpful for students who don't understand the intricacies of make. They just say m2mg <main_module> and then make. They don't have to learn make first. In addition to a fine product, the Sun compiler has another thing going for it: support from the hardware vendor. Upgrades to the OS won't break the compiler and leave you in the lurch until a different vendor massages their product. I expect the 2.1 release (for Sun OS 4.0) of the compiler (which is supposed to have a much better optomizer and fpp support) THIS week. The tape is already in Zuerich. That's service. I'm embarrased to admit this (even though it wasn't my code) but I once e-mailed sun Mt. View megabytes of modula-2 source, complaining about a bug in the compiler. The bug was in the code. The m2 guy at Sun fixed the bug in the M2 source. That's service. That m2 guy is now at Oregon, but Sun continues their commitment to the M2 product and their support. I could ramble on for pages on this topic, and will do so in private e-mail if anyone is interested. I wanted to clear up a few points, namely that there are no "special gubbins," that I am not Chuck, that there is good SCCS support, that the extensions are useful but Sun_OS-specific, and that Sun service is excellent, an important factor. >ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@cs.glasgow.uucp -Mitch -- -Mitchell F. Wyle wyle@ethz.uucp Institut fuer Informatik wyle%ifi.ethz.ch@relay.cs.net ETH Zentrum 8092 Zuerich, Switzerland +41 1 256-5237
nagler%olsen@unizh.UUCP (Robert Nagler) (08/03/88)
>If I were developing a serious product on Suns, I'd probably stick to C; >teaching in an environment where Modula-2 is known requires a M2 compiler. >Sun's is very good for the job. (I won't expound on that point in this >paragraph. ;-) After developing a "serious" system with Sun's M2, I think it is worth a couple of words to "expound" on the subject. I understand the statement that one should "probably stick to C". Believe me, I have had serious doubts about using M2 for our project. One of the first problems anyone runs into is the absolute awful quality of most M2 implementations. Sun's is "pretty good" compared with the others, but it certainly isn't a "production system". We also use Logitech's compiler. We have put in lots of glue to make the development environment "nicer". From past experience with C, the same glue is required. The main reason we haven't used other M2 products is that we write software in Modula-2 as defined in Wirth's books not in the languages supported by Oregon Software, Taylor Modula-2, and the like. These other compilers do not support use before definition. This is probably the biggest stumbling block you will find in Modula-2. If you pick to go with the one-pass compilers, then you won't be able to run with the two-pass compilers and vice-versa. As with any C developer who writes portable software, we have found a great need for a preprocessor. We use it to control what code is compiled. This could help us with the 1-pass/2-pass problem, if we need to switch. Most compilers don't provide conditional compilation and if they do, the control statements are in comments. (Rather silly place for conditional compilation control, if you ask me.) If you aren't developing portable software, then this probably is not that big of an issue. When you develop Modula-2, you need to do IO. Every implementation provides InOut and some other random set of library modules. In order to write portable software, we had to write a portable library which can be ported to different compilers, operating systems, etc. AND the library definition itself must be portable. The library is about 60 modules of which about 10 or so are implementation dependent. This is invaluable feature number 2. And, it allowed us to write the preprocessor in a portable fashion. There is a real advantage in writing your own library (or having the source to one): you can fix bugs and add new features on an as needed basis. There are many other problems one has to solve, but the biggest problem for most people is using a window system from M2. There are many aspects to this problem especially on the Sun. First, which window system do you want to use? You have Suntools, X, and NeWS. We've been tending towards X, because it is "portable" and it runs with NeWS and Suntools. Second, you must interface Modula-2 to the system you choose. With Sun there are two alternatives: SYSTEM.CCALL and DEFINITION FOR C MODULE. We use the latter here, because it makes it easier on the next guy. If you care about portability, then you will probably want to either buy into X or make up your own "standard". We're taking a hybrid approach. In hindsight, Modula-2 is a good system building language. With C++ becoming a new fad, perhaps it is a better choice. It certainly resolves many of the interface issues with C. However, C++ still doesn't have compiled interfaces and a hierarchical naming mechanism, thus M2 still has a considerable advantages. If you choose Modula-2 or C++, you probably have to be committed to it (or just committed). If you aren't willing to make the committment, you probably are better off sticking with a more conventional language such as C (but at least use lint!). Rob olsen!nagler@uunet.uu.net
george@iguanodon.cis.ohio-state.edu (George M. Jones) (09/13/88)
Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes:
There are many other problems one has to solve, but the biggest
problem for most people is using a window system from M2.
...We've been tending towards X, because it is "portable" and
it runs with NeWS and Suntools. Second, you must interface Modula-2
to the system you choose. With Sun there are two alternatives:
SYSTEM.CCALL and DEFINITION FOR C MODULE. We use the latter here,
Have you put togather your own .DEF files ? Is there a set of .DEF files
available for X-Windows with Sun's Modula-2 Compiler ?
---George Jones
-=-
OSU Computer & Inf. Science 2036 Neil Ave.,Columbus,Ohio 43210. 614-292-7325
george@cis.ohio-state.edu or ...!osu-cis!george
Quality of life can be measured as the inverse of lawyers per thousand.