DEC Ada for Alpha Computers

DEC Ada for Alpha Computers

[Loic Briand]

(This is posted for a friend, but you can answer to me)

We are using DEC Ada (native) on DEC Alpha computers under OSF1 Version 3. The
compiler environment has a couple of noticeable flaws, specially the debugger
which does know anything about the Ada specifics (e.g., generic instances,
record components...). 
DEC is using the same technique for OSF1 that for VMS: compilers share the
same backend, which makes possible to link easily several languages in one
executable and to debug all of them, the debugger "adapting" its interface to
the language encounterred at a given point. In other word, the debugger is
language independent: there is only one DEC/OSF1 debugger as there was only
one DEC/VMS debugger. 
The problem is that the debugger needs to have a couple of specific features
implemented for each language. It looks like they were not implemented for Ada
(as they were not implemented if I remember correctly in the first versions
of DEC Ada/VMS). Note also that the debugger is working great with C.

Considering that:
1. There are rumours about DEC health (not much money available to improve the
   existing products - lets concentrate on vital stuff like OSF1 ?),
2. There are rumours that DEC's Ada technology would be bought by Rational
   (is it worth to spend money on a department which will be sold anyway?).
3. DEC Alpha is not exactly a popular host/target,
4. The market for a new Ada83 compiler is dim (9X is happening - why
   invest on Ada83 anymore?),
5. The market for Ada is dim (sad but true),
6. DEC does not provide much information about their plans for Ada/OSF1 (out
   of the usual commercial crap),

is it realistic to hope that DEC will ever fix the problem? If yes, when? 
Is there any alternate solution available today? (I know that Verdix--I mean
Rational has plans for Ada/Alpha but this it not available yet).

The program that needs badly a complete Ada/Alpha environment is currently in
a phase of porting 100.000's LOC from DEC Ada/VMS & Verdix/VMS to Alpha.
This is impossible without a debugger that recognizes at least generic
instances. 

Any help will be appreciated.

BTW, is GNAT ported on Alpha?  :-)




----------------------------------------------------------------------------
--   Loic Briand    lpb@sei.cmu.edu      Office 3308      (412) 268-6674  --
----------------------------------------------------------------------------

Re: DEC Ada for Alpha Computers

[Kent Mitchell]

Loic Briand (lpb@sei.cmu.edu) wrote:
: Is there any alternate solution available today? (I know that Verdix--I mean
: Rational has plans for Ada/Alpha but this it not available yet).

An Alpha/OSF targeted version of the VADS 6.2 product line is availible today.
It includes an Ada debugger that has a lot of interesting language features.
Also, in the merging of Rational Apex and  VADS technologies the trajectory
for this platform is very good (if you like that environment kind of thing).  

Contact prod-info@rational.com for more information.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: DEC Ada for Alpha Computers

[Mats Weber]

In article <1994Sep15.121515.24609@sei.cmu.edu>
lpb@sei.cmu.edu (Loic Briand) writes:

> The problem is that the debugger needs to have a couple of specific features
> implemented for each language. It looks like they were not implemented for Ada
> (as they were not implemented if I remember correctly in the first versions
> of DEC Ada/VMS). Note also that the debugger is working great with C.

> is it realistic to hope that DEC will ever fix the problem? If yes, when? 
> Is there any alternate solution available today? (I know that Verdix--I mean
> Rational has plans for Ada/Alpha but this it not available yet).

I woudn't expect any vendor to fix debugger problems, at least no to a
satisfactory level. I have seen no Ada debugger correctly handling
programs with many generics and tasks. I have been participating in the
development of a project with approx. 100 KLOC, and we have almost
never been able to use a debugger to find the bugs.

Note that this comment should not be taken as Ada bashing. Developping
a debugger for Ada is much harder than for many other languages. And
despite all the tracing we have had to add by hand to our code, I still
wouldn't use any other language for a project of this size.

Re: Ada DEC Ada for Alpha Computers

[Robert I. Eachus]

In article <35af4b$g6@info.epfl.ch> weber@lglsun.epfl.ch (Mats Weber) writes:

 > I woudn't expect any vendor to fix debugger problems, at least no to a
 > satisfactory level. I have seen no Ada debugger correctly handling
 > programs with many generics and tasks. I have been participating in the
 > development of a project with approx. 100 KLOC, and we have almost
 > never been able to use a debugger to find the bugs.

 > Note that this comment should not be taken as Ada bashing. Developping
 > a debugger for Ada is much harder than for many other languages. And
 > despite all the tracing we have had to add by hand to our code, I still
 > wouldn't use any other language for a project of this size.

    Ten years ago I thought that debuggers for tasking programs would
take a while to develop, but that they would come.  I am now convinced
that (in spite of, or perhaps because of the excellent work in Canada
by Ray Buhr and Jerry Karam) debuggers for tasking programs are of no
use whatsoever.

    What you really need is to understand how the tasks can interact,
not how they interact in one specific operation/environment.  This
requires analysis tools which can model the high-level interactions
and detect possible deadlocks, etc.  We have done this at MITRE using
hierarchical colored petri nets.  A lot needs to be done to make the
tools easier to use--you want to extract the model from the code
directly--but I am now convinced that the right place to solve task
interaction problems is on a model.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada DEC Ada for Alpha Computers

[Rick Wilson]

I see an important difference between debugging tasking problems and
debugging multi-tasking applications.  I agree with your point that you
need analysis to debug tasking problems.  However, I have a lot of
experience working with applications containing many dozens of tasks,
and I wish our debugger would handle a statement like "SET a breakpoint
when task x calls routine y."  This, I think, is a shortcoming of all
of our APSEs.  We mostly use DEC's VAX and Alpha compilers/debuggers,
and while not bad, could be much better (the Alpha one in particular is
a bit of a pain).

Re: Ada DEC Ada for Alpha Computers

[Bevin R. Brett]

In article <37epeq$kts@lll-winken.llnl.gov>, rick-wilson@llnl.gov (Rick Wilson) writes...

>of our APSEs.  We mostly use DEC's VAX and Alpha compilers/debuggers,
>and while not bad, could be much better (the Alpha one in particular is
>a bit of a pain).


The debugger for AXP, and especially for OSF/1 AXP, are both very different to
the OpenVMS debugger support; and DEC continues to work on improving both
the AXP debuggers.

/Bevin

Re: DEC Ada for Alpha Computers

[Loic Briand]

To: weber@lglsun.epfl.ch (Mats Weber)
Subject: Re: DEC Ada for Alpha Computers
Fcc: inbox 
--------

In article <35af4b$g6@info.epfl.ch>, you write:
|> In article <1994Sep15.121515.24609@sei.cmu.edu>
|> lpb@sei.cmu.edu (Loic Briand) writes:
|> 
|> > The problem is that the debugger needs to have a couple of specific features
|> > implemented for each language. It looks like they were not implemented for Ada
|> > (as they were not implemented if I remember correctly in the first versions
|> > of DEC Ada/VMS). Note also that the debugger is working great with C. 
[snip]
|> I woudn't expect any vendor to fix debugger problems, at least no to a
|> satisfactory level. I have seen no Ada debugger correctly handling
|> programs with many generics and tasks. I have been participating in the
|> development of a project with approx. 100 KLOC, and we have almost
|> never been able to use a debugger to find the bugs.

I have used high quality Ada debuggers in the past. At least in the case of VAX
Ada, the debugger was able to set break pointw and watch points on any
specific points of specific instances of generics. We were even able (to my
surprise) to set breakpoints in instances of generics that were inside instances
of generics (double-level generics). Also, debugging multitask programs was
possible, though a breakpoint was stopping the whole process, not only one
task (this interesting feature was supposed to be available on DDC-I products). 
I have a similar positive experience with Alsys. 
These experiences were in the context of 500,000 LOCs programs on "serious" 
platforms like VAX or SUN4. 
I have to say that if we had some bad experiences with the first release(s) of
these environments, we always had terrible experiences with all versions of
several PC-based Ada environments, specially with the debuggers which could not 
be considered usable. Meridian used to insert debugging code, which resulted in
having a debug version working, but not the straight one. You can't consider
that such environments are professionnal tools. They are good enough to
learn at home or at school, to develop a couple a toy-size gizmos, but not
100s KLOC multitasking/safety critical/embedded/distributed applications. 
I know that a few teams have done that in the past, and I recognize their
talent. But they would have saved a lot of energy/frustration/money with real
environments on real platforms.
----------------------------------------------------------------------------
--   Loic Briand    lpb@sei.cmu.edu      Office 3308      (412) 268-6674  --
----------------------------------------------------------------------------

Re: DEC Ada for Alpha Computers

[Robert Dewar]

We will be making a binary release of Alpha GNAT (OSF1) available on the
NYU FTP site sometime next week.

Re: DEC Ada for Alpha Computers

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: DEC Ada for Alpha Computers
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



On Thu, 15 Sep 1994 21:06:11, Robert Dewar <dewar@CS.NYU.EDU> writes:
>
>We will be making a binary release of Alpha GNAT (OSF1) available on the
>NYU FTP site sometime next week.
>
Any specifics about system requirements, operating system
versions, etc. that you can elaborate on? I'd like to download it
since I have Alphas available to me, but I'd like to know if I've
got a configuration/OS that can support it before expending lots
of time to find out I've got the wrong box for the job. Thanks.

Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600                  Internet:   4033121@MCIMAIL.COM
===============================================================================
    "If a thing's worth having, it's worth cheating for."

        --  W.C. Fields
===============================================================================

Re: DEC Ada for Alpha Computers

[Richard Kenner]

In article <INFO-ADA%94091609230957@VM1.NODAK.EDU> CONDIC@PSAVAX.PWFL.COM writes:
>Any specifics about system requirements, operating system
>versions, etc. [for GNAT] that you can elaborate on?

OSF/1, should work on V2.0 or V3.0.

Windows NT in a few months.

No plans for VMS (no GCC port to Alpha/VMS yet).