[comp.lang.ada] Help purchasing ADA package for 68020 application

lee@robotics.jpl.nasa.gov (Tom Lee) (12/01/90)

We are planning to purchase an ADA package for writing
real-time application for 68020 target processors. 
We would like to compile our programs on SUN4 to speed up
compilation time.  Naturally we require a cross compiler to
convert over to the 68020 targets.

We are considering 3 packages: Alsys, Verdix, and Telesoft.
My understanding is that Verdix has the worst reputation among these 3.
Do you agree?  Can anyone tell me the pros and cons about these
companies?

We want to request from Alsys a trial version.  Only problem is
that they do not have a SUN4 version.  They say that a SUN4 version
will be available in the early part of 1991 -- I am not sure
whether it will have all the features that their SUN3 version have.
How good are their products?

We have also requested from Verdix.  They have a SUN4 version now,
so we are going to get this one.  Only concern is, for us to
make any meaning comparions (features, speed, etc), we would
like to get the SUN3 version of Verdix to compare with
Alsys's.  But we decided saving compiling time is more important
and that we want to try out the SUN4 version that we are actually
buying, rather than believe on faith that the yet-to-be
released version of Alsys's SUN4 version will be just as good 
as their SUN3 version.

We are not sure whether we want to buy Telesoft's, because theirs
cost $50,000 which is $20K more than those of Alsys and Verdix.

We would like to get any comments on this matter. 

rgc@raybed2.msd.ray.com (RICK CARLE) (12/02/90)

In article <777@forsight.Jpl.Nasa.Gov>, lee@robotics.jpl.nasa.gov (Tom Lee) writes:
> 
> We are planning to purchase an ADA package for writing
> real-time application for 68020 target processors. 
> We would like to compile our programs on SUN4 to speed up
> compilation time.  Naturally we require a cross compiler to
> convert over to the 68020 targets.
> 
> We are considering 3 packages: Alsys, Verdix, and Telesoft.
> My understanding is that Verdix has the worst reputation among these 3.
> Do you agree?...

I don't agree at all.  I don't mean to start a flame war, just express
my opinion based on my personal experiences, but I prefer Verdix Ada
compilers to those of any of the 6 or more other vendors whose products
we've purchased over the last 7 years.

My experience with Verdix has been consistently positive since 1986.
The best things about Verdix compilers have been the strong Unix style
of the software development environment (Unix programmers can feel right
at home with tools such as a.make), fast and highly portable front ends,
and a complete Ada implementation.  Right after those come the excellent
source level symbolic cross-debuggers and the fine run-time system (just
as good, in my opinion, as Ready Systems' and better mated to the
compiler).  Customer support had been weak until about 1989 or so (maybe
earlier), when they beefed up the support staff and streamlined the
customer problem report handling.  Since then, it's been great for me.

(Last November/December I submitted 5 problem reports.  I told Verdix
that 4 were critical for my project and I needed fixes in March.  It was
only 2 weeks before the next version (6.0) was frozen.  One required
rewriting the fixed point arithmetic code generator.  All 4 got into
version 6.0 in March.  That sold me on Verdix customer support.)

The code generators had been only mediocre until version 5.5/5.7
(1988/9).  Since then, they've improved tremendously.  This year's
version, 6.0, has code generators at least as good as any Ada/68020
compiler, with the possible exception of Tartan.  Now the code is fast
and compact.  So is the run-time system.

My personal experience has been mostly with the VAX (Ultrix, Unix, VMS)
implementations of Verdix, except for one set of Ada/workstation
evaluations I did about 3 years ago.  I liked Verdix on the Sun best of
the various Ada/workstation combinations (TeleSoft wasn't included).

These opinions are, of course, strictly my own and not necessarily
shared by my employer.

	Rick Carle