Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uvaarpa!mcnc!ece-csc!ncrcae!ncr-sd!crash!pnet01!haitex From: haitex@pnet01.cts.com (Wade Bickel) Newsgroups: comp.sys.amiga Subject: Re: Anyone seen a good Amiga Pascal lately ? Why not Modula-2? Message-ID: <2652@crash.cts.com> Date: 10 Mar 88 14:56:59 GMT Sender: news@crash.cts.com Organization: People-Net [pnet01], El Cajon CA Lines: 270 [Just a line or three for hungry line eaters] >Dave Haynie writes: >in article <2605@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) says: > >> I use Benchmark Modula-2. It has advantages and disadvantages >> over C. Listing the assets/liabilities of each > >> C: ... > >> + Symbolic Debugger exists (MANX). > > Well, yes, but more than that. Manx ships with a symbolic debugger > and now offers a very nice Source Level debugger as an option. > Lattice doesn't include a symbolic debugger yet, but since they use > the standard Amiga object format, any standard Amiga symbolic > debugger (like MetaScope) will work just fine with Lattice. > Oops! I meant Source Level Debugger. Also, Benchmark must conform to the object format, since it works fine with MetaScope. >More + Manx C allows in-line assembly code > + Manx C can produce native 68020 code and in-line 68881 > code. > >> - C compilers are buggy. > > C compilers WERE much buggier than they are now. Not only that, but > both Manx and Lattice offer BBSs that you can call. Lattice is also > on BIX. I'm using both Manx 3.6 and Lattice 4.0 now, haven't run into > any bugs myself yet. > My point exactly. Benchmark is a infant, whereas MANX and Lattice (like C) are middle aged. Yet Benchmark does not suffer from large numbers of bugs, as did MANX and Lattice. This is a testiment to Benchmarks' quality, which shows at many levels. Furthermore, while MANX and LATTICE are working on non-Amiga products, Avant-Gaurde and OXXI (seperatly) are working on Amiga products. At least 4 products are being developed, or are finished but not yet released. The point is that while MANX or LATTICE depend on bug reports to find bugs Benchmark does not (though of course bug reports are important). >> M2: (Benchmark) >> >> + Integrated Development Environment. This makes using >> Benchmark extremely easy. From the editor (modified >> gnu-EMACs) > > Between running a background Emacs and using MAKE, I find little need > for an integrated enviromnent. Certainly integrated environements > are useful on single-tasking machines, but I'd rather build my own. > For instance, what if I prefer a VI or EDT clone, or a better version > of MG, over the BenchMark MG? Benchmark can be used with any editor you wish. It can be called just like any other compiler so you can use VI if wish, but the EMACs editor is customized and *very* nice. Sure, you can create a multi-tasking solution if you want. By the time your hand is on the mouse I'm compiling! By the time you've typed in your compile commands I'm (probably) Linking! By the time you see your first compiler notice, my program is running! By the time you're done compiling I'm editing my program again! :^) > >> + Compilation Speed. Benchmark is (as best I can compare) >> 8 times faster than MANX C. My test was compilation of >> the program "ShowILBM" under both, as this was a direct >> translation from C to M2. (I don't have Lattice). > > I'd expect the M2 compiler to be a bit faster; both BenchMark and > M2Amiga are based on Wirth's latest M2 compiler, which is a single > pass compiler. Both Amiga compilers are two pass compilers. Not > only that, though, if Benchmark is truely integrated, it'll keep a > copy of the compiler in memory, so your compile time doesn't > reflect the loading of the compiler. On a real short program like > ShowILBM, this makes a big difference. The best comparison would be > to load the Manx or Lattice C compilers into RAM, then try compiling > relatively large programs based on the same programs. I'd call 8 times a bit more than a "bit" faster! Does it matter why? Not to me it doesn't! :^) Yes, Benchmark is "truely integerated". But your comparison comment is irrelavant, because M2 supports seperate compilation in a way that is easy to use and easy to modify. Because of this, ALL PROGRAMS ARE SHORT PROGRAMS! (Well, they compile as if they were, anyway :^>) Also, I put the C compiler in memory anyway, don't you? > >> + M2 includes a statement called "WITH" which supports >> record (structure) access. As far as I can tell >> no equivalent to this statement exists in C (as avail- >> able on the Amiga). This statement leads to both >> more readable (in terms of context) source, and more >> efficeint code. > > I programmed in PASCAL for 4 years, and used WITH alot. It makes > PROGRAMMING easier, since you don't have to include all the contexts > for a reference. It makes support or translation a nightmare, since > you may have no idea, in the case WITHs nested several levels deep, > which individual structure elements belong to which structures. I > ran into this in a port of a large CAD program from Pascal to C. > Bad code is bad code no matter what language it is in! Using nested WITH statements without carefull documentation is BAD coding. For that matter, using nested code of any kind without appropriate documentation is BAD coding. In general I don't nest WITHs in an ambiguous manner (in fact, almost not at all), and this is not hard to do. There just isn't much need to do so. Furthermore, using WITH will cause the refrence address to be placed in an address register, which minimise further address calculations in subsiquent accesses of the WITHed record. This also means that use of scope pointers does not add an address calculation to every access within that scope. [ A scope pointer (my own term) would be a pointer to a structure containing a very large block of data, usually mostly pointers. An example might be a data structure such as a tree, and all data related to that tree.] >> + No Bugs. In the last 6 months Benchmark has never >> Guru'd on me. As far as I (or anyone I've spoken >> with) can tell, this seems to be true. > > I've never had either compiler crash on me. No reason one should, a > compiler is a pretty mild program in terms of what it does to the > system. As for the output of that program crashing, there's always > a tradeoff between the speed of your program and the errors you'd like > the run-time environment to catch for you. This is compiler > independent. > And with Benchmark you can turn runtime error checking on or off as you wish. Also, when I was working with only 512K and one floppy with MANX, it bombed on me regularly. I assume MANX is better now, but v3.20a/b and v3.40a were awful. You probably work on an enhanced system (as I do now) and don't notice some types of problems that can be devastating to the new user working with a minminal system. By the way, I should also point out that Benchmark is much more useable on a minmimal system, compiling/linking 50+ times faster than I was able to coax out of MANX (and yes, I did follow Manx's instructions on how to set things up). >> + Strong Types. M2 uses strong type checking. This makes >> the language easier to learn and debug. > > Lattice has type checking as an option just about as good as any > Modula2. Only it doesn't force it's ideas on you; type violations > show up as warnings, not errors. I usually know from the warning > if a real problem exists or not. > Isn't it just wonderful to recieve a peice of source, compile it, and find a hundred or so "warnings" pop up? Did the author really "know" whether those warnings should be looked into or not? Do they affect my adaptation of the code? When I was in college we were graded down heavily for leaving those "warnings" in our code. Type violations can be gotten around easily enough in M2 >> + Readablility. M2 is much more readable than C. This >> is of value to the novices and group efforts. > > For novices, perhaps. M2 is also quite a bit less writable than C; > it's very verbose. What about group efforts? Readability is crucial here! As far as M2 being "very" verbose, NOT TRUE! In M2 there are a few added words. For instance you must follow the arg of an IF statment with "THEN" instead of "{" and you end the subsiquent statement list with "END" instead of "}". From your statements, I seriously doubt if you've used M2. Like so many, you think M2 is just like PASCAL. WRONG! PASCAL was never intended as a serious working language. > >> Benchmark seems to put out code that is at least as good as Manx-C. > > Size-wise, maybe. If it's a typically M2 compiler, though, it'll > put lots of bounds checking code in the run-time environment. So > I'd expect it to execute slower than a C compiler that otherwise > produces similar quality code. > No, M2 is NOT PASCAL. Your statement is wrong. The code seems to be as compact and as fast as MANX C, as long as you don't turn ON the range checking compiler option. >> I would like to see good comparison. Hopefully we'll see a Benchmark >> symbolic debugger by Summer? Several new "add-ons" are soon to be >> released. > > If that's true, I'd have to tell anyone interested in BenchMark to > wait until that's out before even considering it. You can't do > any serious development without a good debugger, at least a symbolic > one. If they don't support standard Amiga object module symbol > hunks (which would let you use any symbolic debugger), you'd have to > use this without a debugger, and that's death. > 'cuse me again, I meant "SOURCE LEVEL DEBUGGER". I know it already exists, so it's just a matter of time before it is released. As I stated above, Benchmark works great with MetaScope. Of course, most people won't need MetaScope with Benchmark. I've done fine without it. I've written some system level stuff, some copper-list stuff, and a dynamic nested list program, without need of MetaScope, though it is on my list of needed software. (Unless the Debugger is released soon). >> In my opinion Leo, it is not so much the language as the >> implementation that makes the difference. Benchmark is the best >> piece of software I've seen for the Amiga. As far as I can tell >> there is nothing you can do in C you can't do in M2 (except assign >> a "register variable"). Use C if you wish, but Benchmark is worth >> looking into :^). > > One question on that. Can you mix assembler with Benchmark's code? > I know that M2 compilers require intelligent linkers, meaning that > they don't use standard object code, and can't likely be hooked into > code I produce with a standard assembler. If they can't be linked FALSE! As far as I know, Benchmark does not utilize an "intellegent" linker of any type. In fact, I spoke to Leon about just such a mod. The intent would be to have the linker "realize" that a function was never called, and not include it in the code generated (with a compiler option to turn it off, or force inclusion of a module or a segement of a module, of course). Leon pointed out a number of significant difficulties in doing so. It is doable, but the returns are questionable, as well designed modules tend to contain routines which are used together. I suppose you could get the same result if you put only one function in each module, and allowed the compiler to handle "smart linking". > with assembler, is there any support in the Benchmark package for > creating libraries and device drivers on the Amiga? Or in-line > coding of things the compiler doesn't support, like 68020 instructions? > Just curious; without these, you don't have a serious development > system. > Benchmark supports (at least) two methods of assembly support. You can insert op-codes via the "INLINE" command or you can create a module of assembly routines, reference them, and call them. As I understand it OXXI will be adding an INLINE assembler soon. --------------------------------------------- I noticed you left out my references to Modula-2's seperate compilation facilities. This is feature C clearly cannot match. Seperate compiliation in C requires programmer attention to a tremendously higher degree than in Modula-2. ALL my programs use seperate compilation. It's almost as easy as useing #include. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM