Re: Verdix Corp ADA-language development systems

Re: Verdix Corp ADA-language development systems

[Erland Sommarskog]

David E. Emery (dee@linus.UUCP) writes:
>Verdix is 1 of only 2 compilers that that I know to implement code
>sharing of generic bodies.  Furthermore, Verdix does NOT require that
>the body of a generic be compiled before its instantiation.  It is
>possible to write mutually dependent generics (each generic
>instantiates the other) in Verdix, where most compilers will gag on
>such code.  

We're having 5.41 of VADS here for VAX/4.3BSD, and I have written
several error reports on VADS, and more than one of them was on
generics. For instance, the debugger couldn't find the source for 
generic procudure within a generic package. Even more amazing was
to find a generic package to be dependent of its instantiator!

A good point is that if you change a generic body, instantiators
doesn't get invalidated, like they do with DEC/Ada. But the 
recompilation takes a very long time.

Another problem I have had with VADS are the DIANA files. They
get BIG, and *eats* diskquota. (And a.rm doesn't clear away old
instantiations.) To make things worse, units from other libraries
are cached in a local directory. Tip if you plan to use VADS: Get
your own disk, and don't have any quota.
-- 
Erland Sommarskog           
ENEA Data, Stockholm           - Why are Macintosh screens so small?        
sommar@enea.UUCP               - Big Mac is registered by McDonald's.

Verdix Corp ADA-language development systems

[Robert J. Boulanger]

Hello:

I'm looking for some information about ADA development systems from
Verdix Corporation.  Does anyone use or know anything about their
products?  I'm especially interested in their documentation.  How good
is it, and recommnedations do you make for improving it?  How is
Verdix's customer support and training?

Thanks ahead of time for any information.

-- 
Bob Boulanger
bobb@elrond.calcomp.com
(603)885-8072

Re: Verdix Corp ADA-language development systems

[Steven L. Baur]

in article <2410@elrond.CalComp.COM>, bobb@elrond.CalComp.COM (Robert J. Boulanger) says:
> I'm looking for some information about ADA development systems from
> Verdix Corporation.
> ... I'm especially interested in their documentation.  How good
> is it, and recommnedations do you make for improving it?

The documentation on the whole is fair.  I would like to see more details on
how the implementation is done (because of so many potentially expensive
features), and more details on available libraries would be nice too.

All run time libraries are delivered in source code, and that is basically all
the documentation you get.

> How is
> Verdix's customer support and training?

Customer support is weak at best.  They answer the phone rarely, and are
not too terribly helpful.  There is hope though.  The last time I dealt with
customer support, they spent a good deal of time looking at my problem, and
responded formally with written up bug reports.  What will happen next, I
don't know.

Customer training?  If there exists such a beast I have never heard of it.



Currently there exist many problems with verdix ada.  First and foremost is
the release of VADS 5.5 has been suspended because generics do not work,
and the optimizer produces incorrect code.  We bought 5.5 many months ago
(at least January I believe), and still have not received the real 5.5.
There exist many situations where use of NFS file systems completely
confuses the compiler such that it thinks that nothing is up to date
(this can be fixed by touch'ing the objects, but is ugly).
A.make is easily confused into thinking there are circular dependencies
when there aren't.  (Since VADS does not produce .o's in any kind of simple
fashion, the use of make(1) is largely precluded).

A.pr crashes when it sees a form feed.  Verdix ada prints an error message
when it sees a 'pragma page'.
Earlier versions are worse.  Verdix 5.4.1 (the last major release before
5.5) handled generics better, but the run time system had no concept of
critical regions of code.  The interrupt handler could and did interrupt
itself.

The code generator sometimes produces bogus code for arrays that will
generate an exception (bus error, segmentation violation ...) at run time.
This has not occurred in any kind of a fashion that I can repeat, but the
symptoms are such that the array name if treated as pointer, will result in
correct code generated.  The bug always occurs when compiling output from
the Intermetrics ada-yacc which is used in all the Intermetrics tools.

Summary:
If you do not use optimization, and use generics in limited fashion,
Verdix works fine.

Steve  -- ucbvax!trwrb!trwspp!spp2!baur

Verdix Corp ADA-language development systems

[Karl A. Nyberg]

(I would have thought the response to this question would have been more
appropriate for mail, but I'll go with the flow...)

In article <1395@spp2.UUCP> baur@spp2.UUCP (Steven L. Baur) writes:
>in article <2410@elrond.CalComp.COM>, bobb@elrond.CalComp.COM (Robert J. Boulanger) says:
>> I'm looking for some information about ADA development systems from
>> Verdix Corporation.
>> ... I'm especially interested in their documentation.  How good
>> is it, and recommendations do you make for improving it?
...
>All run time libraries are delivered in source code, and that is basically all
>the documentation you get.

I'm running VADS 5.5c on VAX/ULTRIX 2.3, self-target.  In the documentation
that I received, Chapter 18, titled "Implementation Reference", includes
such sections as Parameter Passing, Conversion and Deallocation, Process
Stack Size, Interface Programming, File Formats, some fifteen pages on Run
Time System, another fifteen on Memory Allocation Support in the VADS
Runtime, Bit Manipulation Utilities, Semaphore Services, Task Control
Services, and Exception Reporting.  Maybe you didn't RTFM? :-)

There's even a section titled "Configuring the VADS Run Time System" (17.4),
which is very small for the self-target, but for the VAX/VMS -> 80386 and
VAX/UNIX -> 68000 I recall that these sections run to literally dozens of
pages (I don't have them with me at the moment, so I can't provide EXACT
page counts).

>> How is Verdix's customer support and training?
>Customer support is weak at best.  They answer the phone rarely, and are
>not too terribly helpful.  There is hope though.  The last time I dealt with
>customer support, they spent a good deal of time looking at my problem, and
>responded formally with written up bug reports.  What will happen next, I
>don't know.

My experience has been quite different.  Every time I call I get through and
generally get answers to my problems immediately.  They have an extensive
formal electronic support service for submitting and resolving bugs, a
quarterly users newsletter, a PC running a bulletin board that contains the
latest set of bugs and workarounds.  There's even a users mailing list where
some of us share our problems and solutions independent of their product
support office.  Compare that with the results I've gotten when trying to
submit SPRs to DEC for their Ada under VMS - last time I tried that I was
told the fix wouldn't make it in for two more releases - scheduled a year
and a half out, and that there were no workarounds or any other solutions.

>Customer training?  If there exists such a beast I have never heard of it.

Through an arrangement with Honeywell.  Now you've heard about it. :-) :-)

... many listed "problems" deleted.

I hope you've submitted formal bug reports on these.  Complaining may be
gratifying for the ego, but it's real hard for vendors to fix "Well, the
compiler blew up, and I need a fix" without ACTUAL code.  Generics are
broken one way or another in just about every compiler I've ever used.

Sure, maybe I get SPECIAL service, being as how I'm a Field Test & Beta Test
Site, have a direct 19200 baud uucp connection to support reporting of bugs,
etc., and used to work there.  But "I pays my money and demands my service",
and I'm pleased with the results.

And yes, I STILL own stock in Verdix Corporation.

-- Karl --

Karl A. Nyberg          karl@grebyn.com, nyberg@ajpo.sei.cmu.edu
Grebyn Corporation                 karl%grebyn.com@haven.umd.edu
P. O. Box 1144                        {decuac,haven}!grebyn!karl
Vienna, VA 22180-1144                               703-281-2194

Re: Verdix Corp ADA-language development systems

[David E. Emery]

Our experience with verdix and generics does not match that reported
by baur.  In particular, I personally think that Verdix has the best
implementation of generics of any compiler I've used.  It's not 100% 
perfect, but it's a lot better than most compilers.

Verdix is 1 of only 2 compilers that that I know to implement code
sharing of generic bodies.  Furthermore, Verdix does NOT require that
the body of a generic be compiled before its instantiation.  It is
possible to write mutually dependent generics (each generic
instantiates the other) in Verdix, where most compilers will gag on
such code.  

We're using Vads 5.5(j) on Sun-3.  This release has its problems, but
I don't consider generics an issue.  

Verdix customer support is spotty.  They have some of the brightest
customer people I've worked with, but these people are stretched
fairly thin.  The documentation has gotten much better with 5.5.  
A.make does have some problems, I avoid using it on very large
projects.  There has been a long delay between the time bugs get
reported and isolated and the next release of the compiler that fixes
the bug.   On the other hand, the debugger is nice, although there are
a few bugs and enhancements it could use, too.  It's the easiest
debugger I've used to debug tasks and generics (and tasks in generics,
which is a very rough topic...)

There have been some problems with the optimizer and particularly with
floating point numbers, plus some particularly annoying bugs in static
array initialization (mentioned by baur, but there's a fairly simple
workaround) and variant records (which I think may have been fixed in
5.5j). 

I have no reservations about using Verdix for use on large projects in a
Unix self-hosted environment.  

				dave emery
				emery@mitre-bedford.arpa