From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,INVALID_DATE, UNRESOLVED_TEMPLATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!CIRCUS.LLNL.GOV!IVANOVIC%VAXR From: IVANOVIC%VAXR@CIRCUS.LLNL.GOV ("Vladimir Ivanovic, x3-7786") Newsgroups: comp.lang.ada Subject: Re: Ada Compiler for Educational Use Message-ID: <8805170141.AA17670@ajpo.sei.cmu.edu> Date: 16 May 88 18:29:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: pattis@june.cs.washington.edu (Richard Pattis) asks for comments on Ada compilers. I am using DEC's Ada compiler running under VAX/VMS , its librarian (ACS), the Source Code Analyzer (SCA), the Language Senstitive Editor (LSE), and the symbolic debugger (DEBUG). The error messages from the compiler are excellent, the best I have ever seen. >From within LSE, the compiler will very often attempt a correction of some simple syntactic error, like adding a semi-colon, adding a terminating END IF, or a missing BEGIN. Surprisingly, it is seldom wrong. Errors due to mismatched argument types are also quite good. The compiler tells you which procedures it has checked with which arguments of what type and why it has rejected those attempts at overload resolution. In every case, references to the paragraphs in the LRM which are relevant to the error message are given. LSE knows Ada syntax and will generate stubs for every construct. What it generates is actually user-modifiable, so it's possible to add local coding conventions. Compiler generated machine language code is available, tied to the original source lines. This is a feature I feel is mandatory for any compiler to be called of professional quality. It allows one to distinguish between very subtle bugs in your code, or genuine compiler bugs. The Source Code Analyzer allows almost instant access to every occurrence of an identifier, sorted by whether it is a declaration, a read reference or a write reference. Call trees and inverted call trees can be generated. The full power of SCA is available from within LSE. The debugger is actually language independent. It behaves the same way when you are debugging a routine written in any DEC-supported language. DEC uses the fact that their compilers generate code that follows the VAX/VMS Calling Standard as well as a symbol table convention to permit languages to call routines written in other languages transparently. The debugger does know about features that are particular to Ada, like multi-tasking. It is possible to set break points on task events like TERMINATED or RUN or RENDEZVOUS_EXCEPTION. Naturally, the debugger is a source line, symbolic debugger. You can execute debugger commands on every break, whenever a variable is modified, whenever a particular address is accessed or whenever a particular class of intstruction is used. Effectively you have debugger-aware language. With a little work, it is possible to create an environment where the edit, compile, link and debug cycle is quite fast. I keep one process around for the edit/compile portion and another for the link/debug. One keystroke allows me to switch between them. It's not as integrated as say the Lightspeed Pascal environment is on the Macintosh, but I find it quite good. I'd be hard pressed to suggest improvements, except for the obvious lack of cut and paste between processes/windows. (I have a VaxStation 2000.) I actually cross-compile my programs to a VAXELN machine. (VAXELN is a distributed, real-time operating system toolbox for VAXs that DEC sells and supports.) So I compile, link and use the debugger from one node and run the program on another. A few switches and the operations I do are essentially identical to the single node, vanilla VMS version. I have no hesitation in recommending DEC's Ada system. However, understand that quality is expensive, though DEC does have an educational discount. -- Vladimir