Re: Death of DSP support?

Re: Death of DSP support?

[W. Wesley Groleau x4923]

> AT&T implemented this basic architecture in a wonderful
> processor called the ECOS EMSP.  However, IBM went
> completely bananas attacking it (at the Congressional
> lobbyist level) after we reproduced in 6 coder-months
> a system for the AN/UYS-1 that they had spent 200
> coder-years developing.

For what it's worth, ECOS and the AN/UYS-1 & AN/UYS-2 were also a
significant part of the successful AN/BSY-2 (Seawolf) project.

Re: Death of DSP support?

[Robert Dewar]

Larry says

<<It might be a justifiable business reason, from the view of the
employer, if they also cannot hire anyone who _is_ willing to do
Ada.

Regardless of the general job market, it is possible that some
particular employer might not be able to get anyone to do Ada,
depending on how much else is messed up within the company.>>


Sure, decisions get made for all kinds of reasons, though usually people
who say they can't find Ada programmers don't really want to succeed in
the task anyway, and are just using this as an excuse.

Frankly, if I was hiring programmers for any project who decided that they
could not learn a new language when necessary, I would not want them arond
in any case.

What is interesting though, is that this kind of decision method makes
a mockery of the idea of careful technical evaluation of language
possibilities, resulting in the choice of the best possible technical
solution.

Yes, of course we all know that is rubbish, but a remkarable amount of
rhetoric surrounding the mandate issue seems to actually *believe* in
such rubbish!

Re: Death of DSP support?

[Robert Munck]

On Tue, 26 Aug 1997 07:33:01 -0700, Steven O'Neill
<oneills@top.monad.net> wrote:

>...It appears that, in buying Tartan, TI has seriously curtailed any
>possibility of Ada use in the DSP domain.

I know very little about general DSP programming, but did
a lot of work for NRL in underwater audio (i.e. Sonar) 
signal processing.  We showed pretty conclusively that the
"natural" programming language for that restricted domain
is data flow diagrams.  All of the work done in textual
languages that we saw was a disaster.

This seemed to be true because the great majority of
computation done in a DSP was performed in highly-
specialized SIMD array processors.  These were very
tightly microcoded (horizontal microcode) to do a
small number of SP primitives -- Walsh filters, FFT,
bandwidth, etc.  The control programs, written in Ada
and running in 68K micros, did little more than 
schedule the movement of data between the SIMD machines
and large buffer memories. Rather than hardcode this
logic, we developed a system to interpret encoded DFWs.
Coding was done on a MAC using a CAD/flowcharting tool.

AT&T implemented this basic architecture in a wonderful
processor called the ECOS EMSP.  However, IBM went
completely bananas attacking it (at the Congressional
lobbyist level) after we reproduced in 6 coder-months
a system for the AN/UYS-1 that they had spent 200
coder-years developing.

I don't know if this approach would work as well in
the general case of DSP.

Bob Munck
Mill Creek Systems LC

Re: Death of DSP support?

[Jerry van Dijk]

In article <dewar.872721039@merv> dewar@merv.cs.nyu.edu writes:

>Frankly, if I was hiring programmers for any project who decided that they
>could not learn a new language when necessary, I would not want them arond
>in any case.

The keywords here are <hiring .... any project>. The problem is that you
already have an Ada-unaware staff who's knowledge is needed to keep your
business critical applications running _today_.

A world in which your staff is enthusiastic on technical improvements,
and everything is sufficiently documented to handle more than the usual
turnover does not resemble the current average state of this industry.

Actually, there are a lot of people out there who are determined to keep
it this way, as their bread and butter depend on it...

And yes, I still can get cynical about it.

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Death of DSP support?

[Ken Garlington]

Robert Dewar wrote:
>
> What is interesting though, is that this kind of decision method makes
> a mockery of the idea of careful technical evaluation of language
> possibilities, resulting in the choice of the best possible technical
> solution.

However, to be fair, the NRC study did highlight the point that
"real-world"
language choices have to be based on economic issues as much as
technical
evaluations.

(P.S. Some may note a remarkable similarily between this exception and
a "hypothetical" exception request I posted some time back. I can
neither
confirm nor deny any real-world connection. I can say that, if true,
this
information should not have been posted in a public forum with
specifics,
regardless of the motivation.)

Re: Death of DSP support?

[Ken Garlington]

Robert Munck wrote:
> 
> On Tue, 26 Aug 1997 07:33:01 -0700, Steven O'Neill
> <oneills@top.monad.net> wrote:
> 
> >...It appears that, in buying Tartan, TI has seriously curtailed any
> >possibility of Ada use in the DSP domain.
> 
> I know very little about general DSP programming, but did
> a lot of work for NRL in underwater audio (i.e. Sonar)
> signal processing.  We showed pretty conclusively that the
> "natural" programming language for that restricted domain
> is data flow diagrams.  All of the work done in textual
> languages that we saw was a disaster.

For DSPs used in digital signal processing applications
(what a strange choice :) this is probably true. Lockheed
Martin markets a tool that does data-flow type programming
for radar applications.

However, DSPs can be used for more general processing, and
in some cases it makes sense to do so. For these applications,
it would be nice if Ada were more available.

> 
> Bob Munck
> Mill Creek Systems LC

Re: Death of DSP support?

[Ken Garlington]

Michael & Amy Hartsough wrote:
> 
> I've given a lot of thought to the possibility of trying to
> educate him. I've downloaded the entire "Ada Advocacy package".
> There's some pretty good stuff in there (though it all appears to
> predate the elimination of the mandate). However, I read recently
> that becoming the champion of an unpopular cause is a sure-fire
> way of ruining your career. So I'm not too sure that I want to
> stick my neck out for what appears to be a "lost cause".

I've pretty much _built_ my career (such as it is) by championing
unpopular causes, so I can't agree with this assertion. Be tactful
(don't ask me how, of course), but it's probably worth noting to him
that his competitors still seem to be interested in Ada. You might
ask him why...

Re: Death of DSP support?

[Richard D Riehle]

In article <5u86eg$n8d@bgtnsc02.worldnet.att.net>,
	Michael & Amy Hartsough <Hartsough@worldnet.att.net> wrote:

     [ snip snip snip ]

>A couple of weeks ago, the Director Of Software Engineering at our
>division made a presentation to his staff on the future directions of
>our organization. A bullet on one of his charts stated that because the
>DoD had dropped the Ada Mandate, we will be eliminating Ada and becoming
>a C shop. 

     [ snip snip snip ]

Unfortunately, this is happening at other DoD Ada development shops. 
It is beginning to have its effect on support organizations. On the
brighter side, at least one DoD software manager recently said "The
only two languages I would consider using are Ada and Eiffel.  Moreover,
while the DoD makes the mistake of abrogating its Ada policy, some
non-DoD Software Engineering Directors are beginning to notice
Ada's benefits over C for safety-critical software.  I recently met
one non-DoD software manager who is trying to decide whether to move away
from C++ with either Eiffel or Ada.  Perhaps, as Ada is discovered by real
engineers outside the DoD, it will be able to survive the stupidity of
software managers who abandon Ada for C.  I hope so.

Richard Riehle
AdaWorks

Mars Pathfinder (Was: Re: Death of DSP support?)

[Michael & Amy Hartsough]

Dale Pontius wrote:
> The reentry/landing software for Pathfinder was written in C. They
> interviewed the programmer on TV a while back. He spoke of the 140+
> explosive devices he had to set off at the correct times, that it
> was all written in C, and that he was sweating bullets the entire
> reentry that he might have made some trivial mistake.
> 
> Was Ada even a candidate there? Obviously there's little matter of
> maintenance on such "use once" software, though the need for correct
> behaviour is absolute in such cases. Perhaps more "rapid development"
> tools for Ada are called for, in order to give it a better chance in
> such markets.

This reminds me of something one of the Pathfinder managers
(Matt Golombek?) said during a press conference in the fist few days
after the landing. He was talking about some software problems
they had been having, and he stated that the "fix" was to "change
the priorities of some of the software tasks". This immediately
made me think, "The software's written in Ada?!?" The reason for
my surprise at the thought that it may have been coded in Ada
was because I once worked at JPL (circa 1989), but left because I
saw no commitment to Ada.

Actually, at the time, they were going to write one of the
spacecraft's flight software in Ada (Cassini?) but only because
that was the only compiler available for the selected microprocessor.

Does anyone know if ANY of the Pathfinder software was written in
Ada?

Later,
	Michael

Re: Death of DSP support?

[Michael & Amy Hartsough]

Ken Garlington wrote:
> 
> Michael & Amy Hartsough wrote:
> >
> > However, I read recently
> > that becoming the champion of an unpopular cause is a sure-fire
> > way of ruining your career. So I'm not too sure that I want to
> > stick my neck out for what appears to be a "lost cause".
> 
> I've pretty much _built_ my career (such as it is) by championing
> unpopular causes, so I can't agree with this assertion.

It was in some career guidance book.

> Be tactful

Not exactly my forte.  ;^)


> But it's probably worth noting to him
> that his competitors still seem to be interested in Ada. You might
> ask him why...

This sounds like an interesting approach.

We have "lunchtime" technical seminars, and I was thinking about
putting together a 30 minute presentation using parts of the
Ada advocacy package. Unfortunately, there are some slides in
there that could really use backup charts, and I don't see
any references.

For instance, in Charles Engle's presentation, he quotes some
SEI studies, but doesn't provide any background on what criteria
was used, or how certain "software attributes" were selected.

Later,
	Michael

Re: Death of DSP support?

[Dale Pontius]

In article <5uisg7$k28@sjx-ixn8.ix.netcom.com>,
        Richard D Riehle <laoXhai@ix.netcom.com> writes:
> one non-DoD software manager who is trying to decide whether to move away
> from C++ with either Eiffel or Ada.  Perhaps, as Ada is discovered by real
> engineers outside the DoD, it will be able to survive the stupidity of
> software managers who abandon Ada for C.  I hope so.

There is a corporate phenomenon called, "fast track," which is often
synonymous with , "outrunning your mistakes." In an industry which
fashions itself to have "Web Years" that are under 3 months now, the
C/C++ mindset that favors quick and dirty development seems well
seated and well matched. To dislodge that mindset may well take some
sort of "software disaster" that none of us really want to see.

The reentry/landing software for Pathfinder was written in C. They
interviewed the programmer on TV a while back. He spoke of the 140+
explosive devices he had to set off at the correct times, that it
was all written in C, and that he was sweating bullets the entire
reentry that he might have made some trivial mistake.

Was Ada even a candidate there? Obviously there's little matter of
maintenance on such "use once" software, though the need for correct
behaviour is absolute in such cases. Perhaps more "rapid development"
tools for Ada are called for, in order to give it a better chance in
such markets.

Dale Pontius
(NOT speaking for IBM)

Re: Mars Pathfinder (Was: Re: Death of DSP support?)

[Stephen Leake]

Robert Dewar wrote:
> 
> (just what *is* the universal email symbol for sarcasm, I don't like to use
> a grin, because the thing that distinguishes sarcasm is a serious delivery :-)

Let's invent one: how about :-! (a grin is a curvy mouth, so straight
delivery is a straight mouth).
-- 
- Stephe

Re: Mars Pathfinder (Was: Re: Death of DSP support?)

[Robert Dewar]

<<NASA gave a presentation at TRI-Ada about Cassini (I think). I seem to
recall that they were directed to switch from Ada to C, but my memory
is fuzzy on all of this. Does anyone remember this presentation?>>

Ah ha! Cassini, the gizmo that contains 72 pounds of plutonium that everyone
at NASA is quite sure poses no safety problems right (see NYT this morning :-)
Well it sure gives you an extra feeling of comfort to know that those guys
are doing a good job of carefully selecting a safe language environment.

(just what *is* the universal email symbol for sarcasm, I don't like to use
a grin, because the thing that distinguishes sarcasm is a serious delivery :-)