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.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!ub!planck!corsair!westley From: westley@corsair.uucp (Terry J. Westley) Newsgroups: comp.lang.ada Subject: Re: was compiler bashing Message-ID: <1990Aug16.134728.29012@planck.uucp> Date: 16 Aug 90 13:47:28 GMT References: <155432@<1990Aug10> <20600057@inmet> Sender: news@planck.uucp (Usenet News) Reply-To: westley%hercules@planck.UUCP (Terry J. Westley) Organization: Calspan Corporation ATC Buffalo, NY List-Id: In article <20600057@inmet> ryer@inmet.inmet.com writes: >I truly enjoy compiler bashing. Even if its my own (Intermetrics) compiler, >I enjoy it if it's well done. > >Mike Ryer >Intermetrics I come not to bury Verdix, but to praise them. Instead of compiler bashing, I would like to put in a word for Verdix based on my recent experience. Disclaimer: I don't work for, sell for, or otherwise have an interest in Verdix. I did once own 100 shares of stock, but sold it at a loss about a year ago because it was such a dog. Setting the stage: We are building a distributed, real-time radar simulation. It will run on approx. 35 Sun 4s and 35 Motorola 68030 CPU cards (MVME147) with Ethernet and TCP/IP. COCOMO said it would be around 125K LOC. I believe it will come in closer to 300K. Most of the program is currently in Detail Design (preparing SDDs for you 2167A fans). My group is ahead of this schedule, coding and testing system services such as network communications, terminal I/O, event logging, etc. All of these services have portions which are dependent on the OS and hardware. Our choice for compiler vendor primarily revolved around support for the chosen platforms, especially in the real-time executive and networking software support. We gave most serious consideration to integrations of 1) Telesoft Ada and Ready Systems VRTX, called RTAda, and 2) Verdix Ada and Wind River Systems, called VADSWorks. We initially purchased several copies of Telesoft Ada for the Sun 4s and one copy of Ready's RTAda for the MVME147 target. After doing further work with this system, we rejected it in favor of the Verdix system. We decided against the Telesoft/Ready solution primarily because Ready Systems did not deliver on networking and MVME147 board support that were supposed to be already complete and working. For our specific needs, the Verdix/Wind system was far superior to the Telesoft/Wind. We are currently using the Verdix Ada Sun 4 Self version 6.0.2(g) and the Sun 4 Cross to MVME147 VxWorks (VADSWorks) version 1.3. We have encountered our share of "internal errors," etc. The compiler is by no means perfect. In about one year, we have sent in 5-6 new bug reports. Many were fixed with the very next release. Overall, I would say that Verdix has been very responsive to our problems and worked with us. The problems have been manageable and have not prevented us from continuing our development. Generics are handled quite well, including generics within generics. Passive tasks (their optimization to speed up rendezvous) are an order of magnitude faster than regular tasks, but need to be extended to more situations (including inside generics). I can't say enough good especially about Software Leverage, to whom they have subcontracted support for VADSWorks. SLI has been extremely helpful and very quick to respond. This quick response includes our calling Verdix to formally record a problem or question, have them call SLI, then SLI calls us back to get the details. Two of the best features of VADS are the source level debugger and the make facility. The debugger handles all our code so far, including tasking, generics and C. The same debugger interface works on the Sun host as well as the MVME147 target. The make facility is very smart -- I rarely compile without it. It also works quite will within a Unix make. They both need improvements. The make needs to improve its handling of subunits and the debugger could handle signals better. One major complaint we have yet is the size of the executable images, both for Sun 4 and the target. Verdix claims to be working on a smarter linker that will eliminate the unused portions of packages and the RTS. I hope we see it soon. By the way, lets not start a C vs. Ada discussion on sizes of executables. Its been done to death. I point this out merely to show that I'm not wearing rose-colored lenses. (They're sorta tinted brown, anyway. :-) ) Terry J. Westley Arvin/Calspan Advanced Technology Center P.O. Box 400, Buffalo, NY 14225 acsu.buffalo.edu!planck!hercules!westley