Re: ada and robots

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

Joe Gwinn <gwinn@RES.RAY.COM> writes:
>In practice, C was much more successful than Ada83 at riding metal.
>Experience with Ada83 shows that it is very bad at direct control of
>hardware, especially I/O hardware, and simply does not handle shared
>memory correctly.  Ada95 is claimed to be better, but I don't have any
>direct experience with it.  Actually, not many people do just yet.  I
>suspect that most people are using C (perhaps called from Ada) for direct
>control of I/O hardware and the like.
>
    Maybe with some of the early generation compilers, but we've been
    "riding the metal" for years here in Ada and never had any trouble
    getting direct control over the hardware. Oh sure, once in a while
    you've got to dip into assembler to get at some real hardware
    specific feature, but that's true of *any* language and at least
    Ada specifies a way you can get at machine instructions without
    leaving the compiler.

    Not sure what the problem is you refer to with shared memory, but
    lots of embedded applications never use any shared memory.
    (Between processors? DMA devices? Shared between tasks?) If you
    mean shared between tasks, then Ada95 certainly did improve things
    with protected types, but I as yet have no practical real-time
    experience using protected types to point to as proof that it
    works well. I don't know why it wouldn't. But then, as I recall
    from my C programming days, C had neither any concept of tasks nor
    of shared memory between tasks, which left you "rolling your own"
    if you were multi-threading & sharing memory. If you had to "roll
    your own" in C, why would Ada be fundamentally any worse?

>Most "Ada systems" I have seen built recently are actually mixed-language
>systems, being a mix of C, C++, and Ada, with the Ada being in the
>minority (maybe 25%), if one counts all the purchased COTS code in the
>system.  Typically, the operating system, middleware, and GUI stuff are
>all in C, and the application code is mostly in Ada (with C bindings, and
>no Ada runtime).
>
    This might be true of someone developing under Motif or WindowsNT
    where you have a huge body of code someone else wrote in C that
    you're utilizing. But as I recall, the original post was about
    embedded microcontrollers for robotics and here there is no OS
    except what you build for yourself. (also very little GUI :-) Most
    of the Ada work I've done for either embedded systems or apps
    running under an OS have been 99% Ada and 1% other stuff. I may
    not be "typical" but my experience is that people usually pick a
    language for their app and build from there. The exception being
    if you've inherited some body of software you're trying to glue
    together with other stuff.

>I would also comment that DoD's recent recinding of the Ada Mandate will
>likely cause the Ada compiler and tools market to shrink to perhaps as
>little as one tenth of its prior size, and that significant added
>investment in Ada compilers and tools is therefore unlikely, at least
>until the size of the remaining market becomes clear.  A significant
>shrink is widely expected because the many DoD customers who chose Ada
>because of the mandate will now immediately vanish, and DoD's big push
>towards COTS is in effect a push to C/C++.  The Ada market used to be at
>most one tenth the size of the C market, and things took forever to get to
>the Ada world.  Now, it will be one hundredth.  So, if something Ada is
>not in hand today, don't wait.  It could be a long time coming.
>
    Mandate? We don' have no Mandate! We don' need no steenkin'
    Mandate!!! :-)

    I think this is a sort of self fulfilling prophecy. If Ada is
    technically better, it ought to get fair consideration. (I believe
    it is.) The availability of high quality compilers at reasonable
    cost for a large number of platforms tends to limit any business
    or practical objections to its use. The only case I can see for
    using C in a given app (especially embedded!) is that you can't
    find an adequate Ada environment for the target.

    I believe that if we go out and "Just Do It!" instead of having
    C++ envy, Ada can end up widely successful. Remember that C
    basically sat on the shelf for *years* as a niche language while
    people built stuff out of Fortran, Cobol, assembler, etc. It was
    only recently in its history that it gained any widespread
    popularity.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
West Palm Beach, FL                             Internet:   CONDICMA@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."

        --  G.K. Chesterton
===============================================================================

Re: ada and robots

[Jerry Petrey]

Marin David Condic, 561.796.8997, M/S 731-93 wrote:
> 
> Joe Gwinn <gwinn@RES.RAY.COM> writes:
> >In practice, C was much more successful than Ada83 at riding metal.
> >Experience with Ada83 shows that it is very bad at direct control of
> >hardware, especially I/O hardware, and simply does not handle shared
> >memory correctly.  Ada95 is claimed to be better, but I don't have any
> >direct experience with it.  Actually, not many people do just yet.  I
> >suspect that most people are using C (perhaps called from Ada) for direct
> >control of I/O hardware and the like.
> >
>     Maybe with some of the early generation compilers, but we've been
>     "riding the metal" for years here in Ada and never had any trouble
>     getting direct control over the hardware. Oh sure, once in a while
>     you've got to dip into assembler to get at some real hardware
>     specific feature, but that's true of *any* language and at least
>     Ada specifies a way you can get at machine instructions without
>     leaving the compiler.
> 


I agree.  As I discussed in an "Embedded Systems Programming" article in
Sept 95, I did all the low level hardware checkout and built-in test
software for a gas turbine engine controller in Ada83 using the Rational
VADScross compiler and found it to be quite easy at getting to "the
metal".
I did a lot of bit banging from Ada and used some machine code
insertions
to interface with some ROM based diagnostic routines on the CPU board
to avoid having to re-invent them.  Ada turned out to be an excellent
choice for that project.

I am currently working on a home project of controlling a mobile robot
(with an embedded PC) using Ada.  I only wish Ada was available for some
of the smaller micros like the 68HC11 - for those I now prefer Forth.

-- 
=====================================================================
== Jerry Petrey                                                    ==
== Consultant Software Engineer - Member Team Ada and Team Forth   ==
==            Rockwell Collins Commercial Avionics Group           ==
==            Melbourne, FL   email: gdp@mlb.cca.rockwell.com      ==
=====================================================================

Re: ada and robots

[Alan Brain]

> > Joe Gwinn <gwinn@RES.RAY.COM> writes:
> > >In practice, C was much more successful than Ada83 at riding metal.
> > >Experience with Ada83 shows that it is very bad at direct control of
> > >hardware, especially I/O hardware, and simply does not handle shared
> > >memory correctly.

> Marin David Condic, 561.796.8997, M/S 731-93 wrote:
> >     Maybe with some of the early generation compilers, but we've been
> >     "riding the metal" for years here in Ada and never had any trouble
> >     getting direct control over the hardware.

Jerry Petrey wrote:
> I agree.  As I discussed in an "Embedded Systems Programming" article in
> Sept 95, I did all the low level hardware checkout and built-in test
> software for a gas turbine engine controller in Ada83 using the Rational
> VADScross compiler and found it to be quite easy at getting to "the
> metal".

If Ada-83 is, quote "very bad at direct control of hardware, especially
I/O hardware, and simply does not handle shared memory correctly."
that's news to STN-Atlas Elektronik GmbH.
Submarines in at least 6 navies rely on Ada-83 code that handles shared
memory as the I/O on a VME bus in the CSU-90 and ISUS-90 projects. In
addition, Ada-83 was used extensively for the I/O handling on the BM-502
MFCC consoles on the F-123 class Frigates.
Finally, Ada-83 was used by STN-Atlas on the SEC project, where its
facilities were used by Oerlikon-Contraves Zurich to debug their
software (written in C). The Ada code was so reliable, robust and able
to diagnose problems with incoming telegrams without a debugger and in
real-time. Whereas the C code and that specific deveopment environment
couldn't.

Maybe some early compilers had problems. But not ones built after about
1990.

BTW I was the Team leader for the VME databus comms, and made the
decision to re-write old C code in Ada-83 at the lowest level. Found
bugs in code that had been 'working' with occasional unexplained
glitches for 5 or more years.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: ada and robots

[Joe Gwinn]

In article <339E143A.349D@dynamite.com.au>, aebrain@dynamite.com.au wrote:

> If Ada-83 is, quote "very bad at direct control of hardware, especially
> I/O hardware, and simply does not handle shared memory correctly."
> that's news to STN-Atlas Elektronik GmbH.
> Submarines in at least 6 navies rely on Ada-83 code that handles shared
> memory as the I/O on a VME bus in the CSU-90 and ISUS-90 projects. In
> addition, Ada-83 was used extensively for the I/O handling on the BM-502
> MFCC consoles on the F-123 class Frigates.
> Finally, Ada-83 was used by STN-Atlas on the SEC project, where its
> facilities were used by Oerlikon-Contraves Zurich to debug their
> software (written in C). The Ada code was so reliable, robust and able
> to diagnose problems with incoming telegrams without a debugger and in
> real-time. Whereas the C code and that specific deveopment environment
> couldn't.

There were some Ada compilers that did direct hardware OK, but the code
wasn't portable between Ada compilers.  One could have made many of them
work anyway, but why would you?  Portability was one of the major reasons
for use of Ada.  It was simpler to use assembly for those few bits that
touched I/O registers.

I've seen bad code written in good languages too.  Even in Ada.  Bad
programmers write bad programs.

 
> Maybe some early compilers had problems. But not ones built after about
> 1990.

Are the solutions portable, or simply compiler-by-compiler workable?


> BTW I was the Team leader for the VME databus comms, and made the
> decision to re-write old C code in Ada-83 at the lowest level. Found
> bugs in code that had been 'working' with occasional unexplained
> glitches for 5 or more years.

Whenever one reimplements old code into a new language, any language, one
generally discovers lots of bugs, often to the point that it isn't obvious
how the old code could have worked at all.  


Joe Gwinn

Re: ada and robots

[Robert Dewar]

<<There were some Ada compilers that did direct hardware OK, but the code
wasn't portable between Ada compilers.  One could have made many of them
work anyway, but why would you?  Portability was one of the major reasons
for use of Ada.  It was simpler to use assembly for those few bits that
touched I/O registers.
>>


If you are willing to speak specifics rather than generalities it would be
useful. The generalizations you make are quite incorrect, but it is hard
to argue against vague stuff.

Please demonstrate with VERY SPECIFIC CODE (not some vague reference to
libraries of device drivers) an example of the kind of portable C code
that you are talking about -- hopefully you are talking about ANSI C
code, or at least C code that is well defined in traditional C.

People often make these vague claims, often they come from people who
know very little about the technical details of Ada, but when we see
actual code, we almost always find that the situation in C and
Ada with respect to such support is essentially identical.

Re: ada and robots

[Samuel Mize]

In article <dewar.866044235@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Please demonstrate with VERY SPECIFIC CODE (not some vague reference to
>libraries of device drivers) an example of the kind of portable C code
>that you are talking about -- hopefully you are talking about ANSI C
>code, or at least C code that is well defined in traditional C.

I believe the other poster is missing the point that you are subtly
making: that C code is not well-defined just because it currently works.

C is held to the standard "it compiles and runs."

Ada holds itself to higher standards of formally defined semantics.

If you just want something that happens to run today, by design or
coincidence, you can get by with C.  You can use the preprocessor to
select among a huge number of platform-specific, compiler-specific,
OS-specific code fragments, then claim your code is portable.

Of course, some C is written in a very disciplined and responsible
way.  We can't tar ALL C coders as careless hackers.

Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Re: ada and robots

[Erik Magnuson]

smize@news.imagin.net (Samuel Mize) writes:

> We can't tar ALL C coders as careless hackers.

You know you've been using Unix too long when you parse this as:

	$ tar cvf careless_hackers.tar *.c_coders 

OBAda: I have some (small) sympathy with Joe Gwinn's position that some
combinations of Ada83 compilers may have produced very different
results. Imagine that you used a generic-sharing compiler orginally for a
memory limited system, and then tried to port that code to a similar target
that used expansion instead. Or tasking that mapped tasks to OS processes
vs. run-time scheduling (and you want to do blocking IO in the tasks.)  One
of the phrases I remember least fondly when trying to explain why some
particular code was ill suited to a particular embedded
compiler/runtime/target.
	"But it runs just fine on our Vax using DEC Ada!"

-- 
Erik

Re: ada and robots

[Joe Gwinn]

Robert,

In article <dewar.866044235@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> <<There were some Ada compilers that did direct hardware OK, but the code
> wasn't portable between Ada compilers.  One could have made many of them
> work anyway, but why would you?  Portability was one of the major reasons
> for use of Ada.  It was simpler to use assembly for those few bits that
> touched I/O registers.
> >>
> 
> 
> If you are willing to speak specifics rather than generalities it would be
> useful. The generalizations you make are quite incorrect, but it is hard
> to argue against vague stuff.
> 
> Please demonstrate with VERY SPECIFIC CODE (not some vague reference to
> libraries of device drivers) an example of the kind of portable C code
> that you are talking about -- hopefully you are talking about ANSI C
> code, or at least C code that is well defined in traditional C.
> 
> People often make these vague claims, often they come from people who
> know very little about the technical details of Ada, but when we see
> actual code, we almost always find that the situation in C and
> Ada with respect to such support is essentially identical.

Really, I don't plan to get into such a down in the bits argument; I
haven't the time or energy or reason to fight with you.  Even if I won,
what would I have to show for it?  Fails cost-benefit analysis: All cost,
no benefit.

I do know what my experience has been over the years, and these problems
are echoed by a number of other posters.  If you disagree with my
experience, I'm very sorry, but my experience is what it is.

I would comment that I have been able over the years to get Ada to do many
things then thought impossible by the simple expedient of not asking Ada
to do things she is not well suited to, all hope and hype to the contrary
nonwitstanding.  I have accumulated a list from the days of Ada83.  Many
of these things are nominally fixed in Ada95, which is good, but maturity
takes time, even in compilers.  A little skepticism can go a long way.

Joe Gwinn

Re: ada and robots

[Jon S Anthony]

In article <gwinn-1706972224170001@dh5055155.res.ray.com> gwinn@res.ray.com (Joe Gwinn) writes:

> nonwitstanding.  I have accumulated a list from the days of Ada83.  Many
> of these things are nominally fixed in Ada95, which is good, but maturity
> takes time, even in compilers.  A little skepticism can go a long way.

True, skepticism is always a good thing - up to a point.  But as long
as we are talking personal "experience" here, in my experience, most C
types are neo-ludites.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[Jonathan Guthrie]

In comp.lang.ada Jon S Anthony <jsa@alexandria.organon.com> wrote:

> > nonwitstanding.  I have accumulated a list from the days of Ada83.  Many
> > of these things are nominally fixed in Ada95, which is good, but maturity
> > takes time, even in compilers.  A little skepticism can go a long way.

> True, skepticism is always a good thing - up to a point.  But as long
> as we are talking personal "experience" here, in my experience, most C
> types are neo-ludites.

Not to butt in, but ANY programmer that can be identified as a "language
X person" is likely to be what I believe your calling a "neo-luddite" no
matter what language you're talking about.  Even if that language is
Ada95.

Programmers who are interested in broader language issues learn multiple
languages.  That allows them to collect a larger toolbox to apply to the
problems at hand.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: ada and robots

[Robert Dewar]

Joe says

<<Really, I don't plan to get into such a down in the bits argument; I
haven't the time or energy or reason to fight with you.  Even if I won,
what would I have to show for it?  Fails cost-benefit analysis: All cost,
no benefit.>>

Can't say I am surprised at the refusal to meet the requirement for 
producing actual C code. After all this is the only way that you can
be proved wrong, and why should you risk it? :-)

Re: ada and robots

[Alan Brain]

Joe Gwinn wrote:

> There were some Ada compilers that did direct hardware OK, but the code
> wasn't portable between Ada compilers.  One could have made many of them
> work anyway, but why would you?  Portability was one of the major reasons
> for use of Ada.  It was simpler to use assembly for those few bits that
> touched I/O registers.

Er... the cards concerned were a KAV-30 (DEC compiler) card and a dual
Intel i860 Card (DDCI compiler).
The code was identical, with the exception of the representation
clauses. This was way less that 1 line per 100,000. I'd call that
portable. Especially since it was first run on a MicroVax before
porting.

The others, because of different application domains, only had maybe 40%
of the code in common.
For the SEC, much of the code was written on PCs before porting, using
either a Thomson/Alsys, Meridien or Irvine compiler (Yes, all 3 were
used at one stage, in 2 different continents and 5 different sites).
Target was a mixture of Winterstein/68040 and DecAda/KAV-40.
For the MFCC, much of the code was compiled using the Winterstein
compiler for the 680X0 series, after first being trialed on a Vax.

How much more portable do you want?
 
> I've seen bad code written in good languages too.  Even in Ada.  Bad
> programmers write bad programs.

True, but Irrelevant. A Good programmer, however, can often write a
better program in less time and using less costly tools when using one
language as compared to another.   

> Whenever one reimplements old code into a new language, any language, one
> generally discovers lots of bugs, often to the point that it isn't obvious
> how the old code could have worked at all.

Now there I completely agree! There's a lot to be said for "If it ain't
broke, don't fix it." When you have a good, solid, library, be it in C
or assembler or Cobol or whatever, it's a Black Box. To state the
obvious, all you care about is its external image (what parameters are
passed etc) and what its behaviour is.

Trouble is, much - if not most - COTS software does not perform 100% to
spec. If you're lucky, it just returns bum values. If not, it has memory
leaks, writes to memory way outside its scope etc. This is true for
software written "in-house" as well as purchased. If the library is in a
language with strong typing, with runtime checking possible, then it
greatly decreases the likelihood of errors. If your calling program also
has strong typing and run-time checking, it allows the programmer to
minimise the effects of such problems.
(Example: On the aforesaid project, the D-stepping of the i860 had a
nasty hardware design bug, where when paging, caching, pipelining and
interrupts were all enabled, if an integer load occurred where the
address loaded was within 16 words of the load instruction, and an
interrupt occurred, then the interrupt return register was corrupted.
Usually, but not always, zeroed. Because of the extreme error-recovery
techniques employed, such "branch to random locations in memory" were
liveable with. And more importantly, the behaviour of the system allowed
us to swiftly (well... 6 months....) zero in on the problem. 5 months
and 27 days it took us to eliminate the possibility of a compiler bug. 3
days for me personally to propose the hypothesis, and formulate the
experiment that made the effect reproducible at will, and about 10
minutes to re-work the DDCI compiler's interrupt-handling mechanism to
work around the problem. )

In many another language, such as C or Assembler, I don't see how we
could realistically have tracked down the problem. It would be just "one
of those unexplainable glitches" that are all to common.
  
Much of the argument re C vs Ada can be compared to the old seat-belt
argument. One faction says that a Good Driver without a seat belt is
safer than a bad driver with one. The other is attempting - and failing
- to get across the point that a Good Driver with a seat belt is safer
still, and often a seat belt can save a Bad Driver from being killed.
But enough, I'm straying into generalities, when I only wanted to give a
fairly conclusive counter-example.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: ada and robots

[Joe Gwinn]

In article <339F6D27.4A68@dynamite.com.au>, aebrain@dynamite.com.au wrote:

> Joe Gwinn wrote:
> 
> > There were some Ada compilers that did direct hardware OK, but the code
> > wasn't portable between Ada compilers.  One could have made many of them
> > work anyway, but why would you?  Portability was one of the major reasons
> > for use of Ada.  It was simpler to use assembly for those few bits that
> > touched I/O registers.
> 
> Er... the cards concerned were a KAV-30 (DEC compiler) card and a dual
> Intel i860 Card (DDCI compiler).
> The code was identical, with the exception of the representation
> clauses. This was way less that 1 line per 100,000. I'd call that
> portable. Especially since it was first run on a MicroVax before
> porting.
> 
> The others, because of different application domains, only had maybe 40%
> of the code in common.
> For the SEC, much of the code was written on PCs before porting, using
> either a Thomson/Alsys, Meridien or Irvine compiler (Yes, all 3 were
> used at one stage, in 2 different continents and 5 different sites).
> Target was a mixture of Winterstein/68040 and DecAda/KAV-40.
> For the MFCC, much of the code was compiled using the Winterstein
> compiler for the 680X0 series, after first being trialed on a Vax.
> 
> How much more portable do you want?

I don't doubt your experience, but mine, using different hosts, targets,
and compilers, is different.  In fact, when porting a message-based
middleware system, we had more trouble with Ada compiler differences than
operating system differences.


> > I've seen bad code written in good languages too.  Even in Ada.  Bad
> > programmers write bad programs.
> 
> True, but Irrelevant. A Good programmer, however, can often write a
> better program in less time and using less costly tools when using one
> language as compared to another.   

A truism, but not irrelevant.  There are lots more bad programmers than
good ones.  As far as choice of language goes, what matters is the degree
of match between the problem and the language, and also the quality of the
entire code developments system.


> > Whenever one reimplements old code into a new language, any language, one
> > generally discovers lots of bugs, often to the point that it isn't obvious
> > how the old code could have worked at all.
> 
> Now there I completely agree! There's a lot to be said for "If it ain't
> broke, don't fix it." When you have a good, solid, library, be it in C
> or assembler or Cobol or whatever, it's a Black Box. To state the
> obvious, all you care about is its external image (what parameters are
> passed etc) and what its behaviour is.

The more miles it has on it, the better.


> Trouble is, much - if not most - COTS software does not perform 100% to
> spec. If you're lucky, it just returns bum values. If not, it has memory
> leaks, writes to memory way outside its scope etc. This is true for
> software written "in-house" as well as purchased. 

Isn't this true in general, true of *all* software?  And, if so, language
has nothing to do with it.


> ... If the library is in a
> language with strong typing, with runtime checking possible, then it
> greatly decreases the likelihood of errors. If your calling program also
> has strong typing and run-time checking, it allows the programmer to
> minimise the effects of such problems.

This is a claimed advantage of both Ada and C++.  I have heard lots of
contrary complaints against both languages saying that the protection is
too dearly bought.  It certainly has been the case when attempting to
implement middleware and comms infrastructure, where strong typing is more
hinderance than help.


> (Example: On the aforesaid project, the D-stepping of the i860 had a
> nasty hardware design bug, where when paging, caching, pipelining and
> interrupts were all enabled, if an integer load occurred where the
> address loaded was within 16 words of the load instruction, and an
> interrupt occurred, then the interrupt return register was corrupted.
> Usually, but not always, zeroed. Because of the extreme error-recovery
> techniques employed, such "branch to random locations in memory" were
> liveable with. And more importantly, the behaviour of the system allowed
> us to swiftly (well... 6 months....) zero in on the problem. 5 months
> and 27 days it took us to eliminate the possibility of a compiler bug. 3
> days for me personally to propose the hypothesis, and formulate the
> experiment that made the effect reproducible at will, and about 10
> minutes to re-work the DDCI compiler's interrupt-handling mechanism to
> work around the problem. )
> 
> In many another language, such as C or Assembler, I don't see how we
> could realistically have tracked down the problem. It would be just "one
> of those unexplainable glitches" that are all to common.

Oh, come now.  These kinds of bugs are caught (albeit at great expense)
and fixed all the time, and have been since the first program was written,
in every language imaginable.  I have lots of not fond memories of solving
exactly these sorts of bugs in assembly coded systems.  It's no easier
now, and runtime checks aren't that much help, because random hardware
bugs do not follow the logic of the program, regardless of language.  See
last point.


> Much of the argument re C vs Ada can be compared to the old seat-belt
> argument. One faction says that a Good Driver without a seat belt is
> safer than a bad driver with one. The other is attempting - and failing
> - to get across the point that a Good Driver with a seat belt is safer
> still, and often a seat belt can save a Bad Driver from being killed.
> But enough, I'm straying into generalities, when I only wanted to give a
> fairly conclusive counter-example.

Well, this entire thread reminds me of nothing so much as the discussions
of twenty years ago that my cohorts and I had when we were transitioning
from assembly code to fortran.  Strange to say, it was actually a good
deal easier to debug assembly code than fortran, because, with assembly,
nothing was hidden.  However, fortran was something like four times as
productive as assembly, even though debugging was somewhat harder, so
transition to fortran was an economic necessity.  Still, there was a hard
core of bugs that, even though the code was written in fortran, could only
be solved at the assembly level, because there is a level of logic not
visible to the fortran programmer.  

Likewise, Ada.  Never forget that Ada is a great deal more complex than
fortran, so even more is hidden, even more is assumed.  A few years ago, I
got some of my people out of a jam by debugging their Ada code (of which I
knew almost nothing) at the underlying assembly level.  They could not
figure the problem out after weeks of trying; the information was simply
unavailable at the Ada level.  It took only me a few hours, because I
could see things as they truely were, unconfused by the surface Ada
structure of their program.  The problem turned out to be a classic
Ada-to-OS interface bug: Ada sizes are generally bits, while the OS
expected bytes, so eight times as much data as expected came back from the
OS, causing physically nearby but logically unrelated data structures to
be stomped.  The errors coming from Ada were exactly zero help, but were
numerous and confusing.  

I have accumulated similar fortran, C, and pascal stories over the years.

I guess a fundamental lament is that [most] programmers today don't know
assembly, are even frightened of it, so when something like this happens,
they're helpless.  I saw this problem in the days of fortran, and I still
see it today.

Joe Gwinn

Re: ada and robots

[Spam Hater]

> .... There's a lot to be said for "If it ain't
> broke, don't fix it." When you have a good, solid, library, be it in C
> or assembler or Cobol or whatever, it's a Black Box. ....

IMHO, the second rule is, "If nobody understands it, it's broke."

> .... To state the
> obvious, all you care about is its external image (what parameters are
> passed etc) and what its behaviour is.
> Trouble is, much - if not most - COTS software does not perform 100% 

And this is why.

----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                 wwgrol  AT   pseserv6.fw.hac.com
Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
in it is trespassing!
----------------------------------------------------------------------

Re: Ada and robots

[Huy Vo]

>Wes Groleau wrote:
>
>
>
> don't know a C compiler that doesn't have __LINE__. Do you?
> > >Yes, the LSI-11/02 and Turbo C++ 2.
> > I wouldn't worry much what a DEC compiler has to say.
>
> "Everybody's doing it...."  "DEC isn't"  "DEC doesn't count"
> Sounds like "What have the Romans ever done for us?" in _Life_of_Brian_
>

#include stdio.h

appears to be an acceptable form according  to Kernighan & Ritchie 2; I doubt
the standard will say otherwise. I stand corrected.

Re: Ada and robots

[Richard A. O'Keefe]

Huy Vo <vo@CTRON.COM> writes:

>#include stdio.h

>appears to be an acceptable form according  to Kernighan & Ritchie 2; I doubt
>the standard will say otherwise. I stand corrected.

The standard does say otherwise.

	#include <stuff>			is standard
	#include "stuff"			is standard
	#include macro				is standard

The third form is important and useful (and tricky, because the "stuff" is
not a string literal, and <stuff> isn't like any other token in C, but
the macro call is made of normal C tokens).  However,

	#include stuff.stuff			is NOT standard

There would be no problem with
	#include stdio
but for that to be meaningful, stdio would have to be a macro that was
defined to expand to one of the other forms.

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and robots

[Huy Vo]

aebrain@dynamite.com.au (Alan Brain) wrote
>
>Huy Vo wrote:
>
>> I don't know a C compiler that doesn't have __LINE__. Do you?
>
>DEC LSI-11/02 C for RTS-11SJ. The first time I did an embedded system in
>C, back in 1978.
>
>Turbo C++ 2.0 has problems with __LINE__ too, and I'll check with MVC++
>5 and CW 10, CW 12 to see if they give identical results.
>
>> Do you know of 2 compilers that will not agree on the value of __LINE__
>> in the  following program:
>
>> #include <stdio.h> /* since you insist on having this */
>>
>> main() {
>>         printf("the value of __LINE__ is independent of the compiler %d\n",
>>  __LINE__);
>>         return 0;
>> }
>
>Yes, the LSI-11/02 and Turbo C++ 2.
>


DEC has a compiler that accepts this line
include stdio.h      /* no brackets */
given the kind of liberty they allow the compiler to have,
I wouldn't worry much what a DEC compiler has to say.

I don't know where you digged out your copy of Turbo C;
mine (Turbo C 4.5.1 ) compiles __LINE__ without a blink; if your compiler had
 problem with __LINE__ then it's a bug, and not a portability issue.

The following compilers have  __LINE__:
Metaware Hi-C
Sun cc and Sun acc
gcc
AIX xlc
Microsoft 7.1
Mix Power C
That's 7 modern compilers againts your ancient DEC compiler.
I am sure the list is not exhaustive. If only 5 out of 10 Ada compilers
provided an mechanism equivalent to __LINE__, would you forget the portability
crap and use it, or are you  still saying "Gee, I can't use this functionality
because only half the compilers have it. I just have to hard code in the line
 number
to make my code portable." IMHO, if there is a worse thing than goto then it has
 to
be hard coded constants. You brought up the portability
issue, whereas I intended to use __LINE__ solely as a  method of debugging.

Re: Ada and robots

[Wes Groleau]

> >> I don't know a C compiler that doesn't have __LINE__. Do you?
> >Yes, the LSI-11/02 and Turbo C++ 2.
> I wouldn't worry much what a DEC compiler has to say.

"Everybody's doing it...."  "DEC isn't"  "DEC doesn't count"
Sounds like "What have the Romans ever done for us?" in _Life_of_Brian_

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada and robots

[Huy Vo]

>In Ada-83,
>
>when STORAGE_ERROR =>
> PUT("Storage Error for Module: " & ModuleName & "  At line: ");
>  PUT(LineCount);
>   raise;
>
>   Naturally this means you must set variables ModuleName (a string) and
>   LineCount (a positive) in the code. You also need to have
>
>       with TEXT_IO; use TEXT_IO.
>
>       and
>
>        exception
>
>        somewheres. But as your C code didn't mention the #includes required
 for
>        the use of stderr, fprintf, and the non-portable definition of __LINE__
>        I think this is fair. Especially since the Ada is completely portable.
>
>        Oh yes, the "raise" statement doesn't just give a meaningless error
 code
>        (1), it tells the caller that this is a STORAGE_ERROR, and allows them
>        to use a different technique/algorithm that won't be so
>        memory-intensive.
>
Basically you have to hard code the line number in the code?
And everytime you add or delete something before that line, you change
that hard coded number again? __LINE__ is supposed preprocessed by
a program so the programmer doesn't have to count. As to portability,
I don't know a C compiler that doesn't have __LINE__. Do you?
Do you know of 2 compilers that will not agree on the value of __LINE__
in the  following program:


#include <stdio.h> /* since you insist on having this */

main() {
        printf("the value of __LINE__ is independent of the compiler %d\n",
 __LINE__);
        return 0;
}

Re: Ada and robots

[Alan Brain]

Huy Vo wrote:

> I don't know a C compiler that doesn't have __LINE__. Do you?

DEC LSI-11/02 C for RTS-11SJ. The first time I did an embedded system in
C, back in 1978.

Turbo C++ 2.0 has problems with __LINE__ too, and I'll check with MVC++
5 and CW 10, CW 12 to see if they give identical results. 

> Do you know of 2 compilers that will not agree on the value of __LINE__
> in the  following program:

> #include <stdio.h> /* since you insist on having this */
> 
> main() {
>         printf("the value of __LINE__ is independent of the compiler %d\n",
>  __LINE__);
>         return 0;
> }

Yes, the LSI-11/02 and Turbo C++ 2.
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Ada and robots

[Will Rose]

Alan Brain (aebrain@dynamite.com.au) wrote:
: Huy Vo wrote:

: > I don't know a C compiler that doesn't have __LINE__. Do you?

: DEC LSI-11/02 C for RTS-11SJ. The first time I did an embedded system in
: C, back in 1978.

__LINE__'s ANSI - my BDS C compiler doesn't have it, but I don't let
that deter me from using __LINE__ (or BDS C, where appropriate).

Will
cwr@crash.cts.com

Re: Ada and robots

[Mattias Sj�sv�rd]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]


Huy Vo wrote:

> Basically you have to hard code the line number in the code?
> And everytime you add or delete something before that line, you change
> that hard coded number again? __LINE__ is supposed preprocessed by
> a program so the programmer doesn't have to count. As to portability,
> I don't know a C compiler that doesn't have __LINE__. Do you?

I know several. In fact no C compiler understands __LINE__. 
The standard preprocessor cpp does however understand __LINE__.
It is perfectly possible to use cpp on Ada source as well, but
I wouldn't recommend it.
Decent version control systems usually supply a way to get the
integer literal of the current line number inserted in the source.

/Sj�sv�rd

re: Ada and robots

[John Howard]

Adding comp.lang.ada

On Sat, 28 Jun 1997 puk@tc.umn.edu wrote:
> I don't understand how Ada got it's undeserved reputation
> of inadequate low-level interfacing capabilities. My guess
> is that it is somehow related to the C and assembly culture
> that says low-level interface code has to look a certain
> way, i.e. concise statements such as: r = (x << 2) && 8
> I have heard many a software person say this is how they can
> get to the "bare metal".

My guess is novices starting to program during the 1980's and accepting 
hearsay about early Ada systems as the gospel truth from then until
doomsday. (Byte magazine was very influential back then. Many people would 
also rely on the ads to see what was happening. Ads for Ada dwindled
because the readership was mostly PC oriented on miniscule systems. The
lasting impression was Ada was big, slow, overly protective, overly 
priced, and overkill for what you wanted to do.)

Justifiably some of the hearsay was true about those old Ada systems. But 
now there is a *new and improved* Ada standardized in 1995. With Ada you 
can usually code in assembler or use intrinsics when you have to. And
using Ada protected types with multitasking on the bare metal has the 
potential to provide speed and efficiency that even C can't match. 
Although a custom RTOS (designed with protected types in mind) + C
solution would be able to offer similar benefits.

www.adahome.com to see for yourself

> The reality of the situation is that the "bare metal" can be
> synthesized through a Hardware Description Language such as VHDL,
> which in fact has a very similar syntactical representation to Ada.
> Whole processor cores for devices such as the 8051 can be purchased
> as VHDL source code.
>
> A quiz: Which of the following package specs is Ada and which is VHDL?
>
> -- Language X
> library Bit_Level;
> use Bit_Level.all;
> package Register_File is
>
>    type R_File is array (Reg'Range) of Bit;
> 
> end Register_File;
> 
> -- Language Y
> with Bit_Level;
> use Bit_Level;
> package Register_File is
>
>    type R_File is array (Reg'Range) of Bit;
>
> end Register_File;

Good point.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: Ada and robots

[Huy Vo]

jsa@alexandria.organon.com (Jon S Anthony) wrote:

>In article <9706242128.AA09652@stealth.ctron.com> Huy Vo <vo@CTRON.COM> writes:
>
>> >a) No one is dumb enough to suggest Ada programs are by nature some
>> >how bug free.  So, you are just giving a silly strawman
>>
>> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
>> I should think twice.
>
>Whatever floats your boat.
>
>
>> As a C programmer, I know it better than anyone; so I have been
>> religiously checking every malloc()'s return and proceed
>> accordingly.  What do you do when you call new and new fails?
>
>Whatever is appropriate.
>
>> You rely on the runtime system telling you what line it fails?
>
>No.  All such stuff should be isolated with a non-lowlevel interface.
>Inside the implementation exception handler(s) take the appropriate
>action.  Outside, no one cares or needs to care.


Someone has to care, Jon. Because  if you dynamically  allocate memory
at 101 places in your 100K lines of code and only one of
the allocations failed, you really want to know which one failed.
As an application programmer what would you do? As a compiler writer
that has to provide a default handler for this type of situation
what would you do?

In C, it's as simple as

  if (!(cp =malloc(BIG_CHUNK)) {
    fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
    exit(1);
   }

Show me your code.

Re: Ada and robots

[Wes Groleau]

Huy Vo wrote:
> 
> jsa@alexandria.organon.com (Jon S Anthony) wrote:
> 
> >In article <9706242128.AA09652@stealth.ctron.com> Huy Vo <vo@CTRON.COM> writes:
> >
> >> >a) No one is dumb enough to suggest Ada programs are by nature some
> >> >how bug free.  So, you are just giving a silly strawman
> >>
> >> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
> >> I should think twice.
> >
> >Whatever floats your boat.
> >
> >
> >> As a C programmer, I know it better than anyone; so I have been
> >> religiously checking every malloc()'s return and proceed
> >> accordingly.  What do you do when you call new and new fails?
> >
> Someone has to care, Jon. Because  if you dynamically  allocate memory
> at 101 places in your 100K lines of code and only one of
> the allocations failed, you really want to know which one failed.
> As an application programmer what would you do? As a compiler writer
> that has to provide a default handler for this type of situation
> what would you do?
> 
> In C, it's as simple as
> 
>   if (!(cp =malloc(BIG_CHUNK)) {
>     fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
>     exit(1);
>    }
> 
> Show me your code.

I don't have time to show you my code.  But I am not about to
put such a Put_Line at a hundred and one places in the code
(though it is possible in combination with SCCS and an exception
handler).

Neither would I allow my customer to see such a message if I 
could prevent it.  I just tell the debugger to break on 
Storage_Error and if it happens, show stack.  (Better yet, 
have a stack trace in Ada.Exceptions.Exception_Information--but 
that thread is still in progress...)

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada and robots

[nma123]

In article , Huy says...
>
>jsa@alexandria.organon.com (Jon S Anthony) wrote:
>
>>In article <9706242128.AA09652@stealth.ctron.com> Huy Vo <vo@CTRON.COM> writes:
>>
>>> >a) No one is dumb enough to suggest Ada programs are by nature some
>>> >how bug free.  So, you are just giving a silly strawman
>>>
>>> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
>>> I should think twice.
>>
>>Whatever floats your boat.
>>
>>
>>> As a C programmer, I know it better than anyone; so I have been
>>> religiously checking every malloc()'s return and proceed
>>> accordingly.  What do you do when you call new and new fails?
>>
>>Whatever is appropriate.
>>
>>> You rely on the runtime system telling you what line it fails?
>>
>>No.  All such stuff should be isolated with a non-lowlevel interface.
>>Inside the implementation exception handler(s) take the appropriate
>>action.  Outside, no one cares or needs to care.
>
>
>Someone has to care, Jon. Because  if you dynamically  allocate memory
>at 101 places in your 100K lines of code and only one of
>the allocations failed, you really want to know which one failed.
>As an application programmer what would you do? As a compiler writer
>that has to provide a default handler for this type of situation
>what would you do?
>
>In C, it's as simple as
>
>  if (!(cp =malloc(BIG_CHUNK)) {
>    fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
>    exit(1);
>   }
>
>Show me your code.

off course you dont want to do the above in a real program. 

Nasser

Re: Ada and robots

[Richard A. O'Keefe]

Huy Vo <vo@CTRON.COM> writes:
>In C, it's as simple as

>  if (!(cp =malloc(BIG_CHUNK)) {
>    fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
>    exit(1);
>   }

A nice example of what can go wrong with C.
(1) exit(1) is not portable.  (At my suggestion, lclint can check for this.)
    In some important C systems, exit(1) indicates _success_, not failure.
    It should be exit(EXIT_FAILURE), or better still, abort().

(2) A typical C program has many more source files than one.  If you tell
    me what line number, what good does that do?

(3) "Good" C for this would be something like
	#define New(p, n) \
	    if (((p) = malloc((n))) != 0) {} else assert(!"malloc failed")
    which will, I'm afraid, provoke warnings from lint and other checkers
    (empty if-part, constant condition).

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada and robots

[Alan Brain]

Huy Vo wrote:

> Someone has to care, Jon. Because  if you dynamically  allocate memory
> at 101 places in your 100K lines of code and only one of
> the allocations failed, you really want to know which one failed.
> As an application programmer what would you do? As a compiler writer
> that has to provide a default handler for this type of situation
> what would you do?
> 
> In C, it's as simple as
> 
>   if (!(cp =malloc(BIG_CHUNK)) {
>     fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
>     exit(1);
>    }
> 
> Show me your code.

In Ada-83,

when STORAGE_ERROR =>
 PUT("Storage Error for Module: " & ModuleName & "  At line: ");
 PUT(LineCount);
 raise;

Naturally this means you must set variables ModuleName (a string) and
LineCount (a positive) in the code. You also need to have

 with TEXT_IO; use TEXT_IO.  

and

 exception

somewheres. But as your C code didn't mention the #includes required for
the use of stderr, fprintf, and the non-portable definition of __LINE__
I think this is fair. Especially since the Ada is completely portable.

Oh yes, the "raise" statement doesn't just give a meaningless error code
(1), it tells the caller that this is a STORAGE_ERROR, and allows them
to use a different technique/algorithm that won't be so
memory-intensive.
   
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Ada and robots

[Stephen Leake]

Alan Brain wrote (in part):

> But as your C code didn't mention the #includes required for
> the use of stderr, fprintf, and the non-portable definition of __LINE__
> I think this is fair. Especially since the Ada is completely portable.

To be truly fair, remember that __LINE__ is defined by ANSI C, and is
therefore as portable as anything defined in Ada 95. This is one
facility that Ada 95 does NOT have; it requires a pre-processor to
support it. ANSI C defines a pre-processor; Ada 95 does not.

The rest of Alan's critique is well taken!
-- 
- Stephe

Re: Ada and robots

[Wes Groleau]

> when STORAGE_ERROR =>
>  PUT("Storage Error for Module: " & ModuleName & "  At line: ");
>  PUT(LineCount);
>  raise;
> 
> Naturally this means you must set variables ModuleName (a string) and
> LineCount (a positive) in the code. You also need to have

Without actually envouraging the above technique, let me mention that
many primitive configuration management tools like SCCS allow you
to embed certain strings that are automatically converted to things
like "date checked in" "module name" "line number" "version number"
etc.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada and robots

[Jon S Anthony]

In article <9706262213.AA13647@stealth.ctron.com> Huy Vo <vo@CTRON.COM> writes:

> >> You rely on the runtime system telling you what line it fails?
> >
> >No.  All such stuff should be isolated with a non-lowlevel interface.
> >Inside the implementation exception handler(s) take the appropriate
> >action.  Outside, no one cares or needs to care.
> 
> 
> Someone has to care, Jon. Because  if you dynamically  allocate memory
> at 101 places in your 100K lines of code and only one of
> the allocations failed, you really want to know which one failed.

Hardly.  In general, that will not be at all informative.  The problem
will have been caused by a memory _leak_ - for which, who's attempting
final allocation is completely irrelevant.


> As an application programmer what would you do? As a compiler writer
> that has to provide a default handler for this type of situation
> what would you do?
> 
> In C, it's as simple as
> 
>   if (!(cp =malloc(BIG_CHUNK)) {
>     fprintf(stderr, "Buy some more ram, i died at line %d\n", __LINE__);
>     exit(1);
>    }

This is a joke, right?  Anyone I ever see writing god-awful code like
the above would get sent back for some remedial lessons.


> Show me your code.

Equivalent lousy Ada code:

exception
    when E : Storage_Error =>
	Put_Line(
	    Exception_Name(E) & ": " & Exception_Information(E) &
            "In function Parser.Parse_Derived_Type_Def.Array_Type," &
            when attempting to allocate node for anonymous array type." );


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Ada and robots

[Huy Vo]

jsa@alexandria.organon.com (Jon S Anthony) wrote:
>In article <199706201607.MAA01178@mermaid.ctron.com> Huy Vo <vo@CTRON.COM>
 writes:
>
>> >Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
>> >it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)
>> >
>> Safe or not safe, it looks like Ada programs can crash on the field like
>> a previous poster admitted. The worse thing is that it leaves no trace
>> as to what leads to the crash.  And other posters have to come up with
>> ugly 'C hacks'  to provide traceback of Ada programs. There goes the myth
>> that Ada programs need no debugging.
>
>a) No one is dumb enough to suggest Ada programs are by nature some
>how bug free.  So, you are just giving a silly strawman

Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
I should think twice. By the way, aren't there components on a Boeing
that are based on 8 bit processors that can't take C let alone Ada.
So what is the justification of insisting on building supposedly
safe systems (the Boeing)  with a mix of safe components (Ada) and
unsafe ones (C and assembly)?

>
>b) Trace backs or not are _implementation_ dependent.  Plenty of C
>implementations have nothing to offer here either (put together with
>the fact that most have absolutely worthless compile time diagnostics
>and you have something that basically offers zero support).

As a C programmer, I know it better than anyone; so I have been
religiously checking every malloc()'s return and proceed accordingly.
What do you do when you call new and new fails? You rely on the runtime system
 telling
you what line it fails? Unlikely, since the runtime is not required to do this.
How many of you actually have a customized "out of memory" handler
that indicates what exactly the offending line?
Error checking is an attitude; it's not a feature of the language.

>
>c) In this particular case (fiddling with machine level
>representations) the most you can conclude from your "comment" is that
>neither has an advantage over the other, i.e., for this _particular_
>case, you claim that it's a wash.
>
>d) Even in HW interfacing there is a _lot_ more going on than the
>actual machine level fiddling.  This work invariably requires
>(implicitly or explicitly) higher level abstractions.
>
>e) No one is dumb enough to suggest C has high level abstraction
>capabilities such as found in Ada.

On the contrary, C constitutes the low level base for Ada programs,
the work horse, the "unsafe" layer (NT, UNIX, LINUX, etc...) without which
it's impossible to build "safe" applications. The lack of high level abstraction
doesn't hurt C a bit. C provides me with every component that made this post
possible: the editor, the operating system, the networking software/firmware.
I don't believe in C because everyone (well, almost) writes in C; I believe
in C because it works just fine for me.

Re: Ada and robots

[Jon S Anthony]

In article <9706242128.AA09652@stealth.ctron.com> Huy Vo <vo@CTRON.COM> writes:

> >a) No one is dumb enough to suggest Ada programs are by nature some
> >how bug free.  So, you are just giving a silly strawman
> 
> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
> I should think twice.

Whatever floats your boat.


> As a C programmer, I know it better than anyone; so I have been
> religiously checking every malloc()'s return and proceed
> accordingly.  What do you do when you call new and new fails?

Whatever is appropriate.

> You rely on the runtime system telling you what line it fails?

No.  All such stuff should be isolated with a non-lowlevel interface.
Inside the implementation exception handler(s) take the appropriate
action.  Outside, no one cares or needs to care.


> Error checking is an attitude; it's not a feature of the language.

Yes and no.  I prefer to have whatever reasonable extra support there
is.


> On the contrary, C constitutes the low level base for Ada programs,

??? This is incomprehensible.

> the work horse, the "unsafe" layer (NT, UNIX, LINUX, etc...) without
> which it's impossible to build "safe" applications.

This is outright nonsense.


> believe in C because everyone (well, almost) writes in C; I believe
> in C because it works just fine for me.

A VB programmer offers the same justification.  As does the assembly
as does ..., i.e., this is no justification at all.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Ada and robots

[Alan Brain]

Huy Vo wrote:

> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
> I should think twice. By the way, aren't there components on a Boeing
> that are based on 8 bit processors that can't take C let alone Ada.
> So what is the justification of insisting on building supposedly
> safe systems (the Boeing)  with a mix of safe components (Ada) and
> unsafe ones (C and assembly)?

OK, here's a facetious reply:

Good idea. Rip out all safety belts from cars, ban airbags, take away
headlights (headlights don't prevent ALL car crashes at night, therefore
there's no reason to have them, right?), remove the brakes (brakes won't
save you from being hit from the side, therefore remove them as
un-neccessary). 

There is one heck of a difference between having 4-5 lines per million
which are as (un)safe as C casts, are confined to known locations, and
where one can write explicit safety code around, rather than having 4-5
of these per 100 lines.

As regards 8-bit components on the Boeings, you may well be right. I
have no idea what controllers are on the microwave ovens, for example.
But the safety-critical avionics aren't 8-bit. Neither in the cockpit
controls, nor the navigation system, nor the engines.

Never mind, I assume this was a "rattle their cage" troll, so I'll leave
it go. Unless you can adduce some logical argument, further dielectic
would be futile.
  
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
100026.2014 compuserve o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale
See http://www.z-world.com/graphics/z/master/8856.gif for picture

Re: Ada and robots

[Dale Stanbrough]

Huy Vo writes:

"On the contrary, C constitutes the low level base for Ada programs,
 the work horse, the "unsafe" layer (NT, UNIX, LINUX, etc...) without which
 it's impossible to build "safe" applications. The lack of high level
abstraction
 doesn't hurt C a bit. C provides me with every component that made this post
 possible: the editor, the operating system, the networking
software/firmware.
 I don't believe in C because everyone (well, almost) writes in C; I believe
 in C because it works just fine for me."

Perhaps you should look at a Comms. of the ACM article in which standard
Unix utilities such were fed a series of random characters as a test.
Many of them core dumped. We can't infer that just because something is being
used all the time, and that it is written in a particular language, that 
therefore that language is intrinsically good.


Dale

Re: Ada and robots

[Wes Groleau]

> So what is the justification of insisting on building supposedly
> safe systems (the Boeing)  with a mix of safe components (Ada) and
> unsafe ones (C and assembly)?

To be a little more accurate, use the terms "low-risk" and 
"high-risk".  Then the answer becomes:

  The justification is that a majority of low-risk software mixed
  with a little high-risk software is better than using only
  high-risk software.

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: Ada and robots

[Ken Garlington]

Huy Vo wrote:
> 
> jsa@alexandria.organon.com (Jon S Anthony) wrote:
> >In article <199706201607.MAA01178@mermaid.ctron.com> Huy Vo <vo@CTRON.COM>
>  writes:
> >
> >> >Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
> >> >it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)
> >> >
> >> Safe or not safe, it looks like Ada programs can crash on the field like
> >> a previous poster admitted. The worse thing is that it leaves no trace
> >> as to what leads to the crash.  And other posters have to come up with
> >> ugly 'C hacks'  to provide traceback of Ada programs. There goes the myth
> >> that Ada programs need no debugging.
> >
> >a) No one is dumb enough to suggest Ada programs are by nature some
> >how bug free.  So, you are just giving a silly strawman
> 
> Cool; Ada is not as safe as I thought it was; so, when I board a Boeing
> I should think twice. By the way, aren't there components on a Boeing
> that are based on 8 bit processors that can't take C let alone Ada.
> So what is the justification of insisting on building supposedly
> safe systems (the Boeing)  with a mix of safe components (Ada) and
> unsafe ones (C and assembly)?

Because it's safer than building it in pure assembly.

You don't _really_ believe systems are "safe" vs. "unsafe", do you?
Systems are _relatively_ safe vs. other systems. There's several good
books on this subject; see (for example)

  http://www.cs.washington.edu/research/projects/safety/www/

> 
> >
> >b) Trace backs or not are _implementation_ dependent.  Plenty of C
> >implementations have nothing to offer here either (put together with
> >the fact that most have absolutely worthless compile time diagnostics
> >and you have something that basically offers zero support).
> 
> As a C programmer, I know it better than anyone; so I have been
> religiously checking every malloc()'s return and proceed accordingly.
> What do you do when you call new and new fails? You rely on the runtime system
>  telling
> you what line it fails? Unlikely, since the runtime is not required to do this.

In Ada, of course, it _is_ required to tell you (see the exception
Storage_Check,
described in section 11.5:23 of the language reference manual). Coupled
with a
good debugging environment, the line number where the check occured will
be
reported.

> How many of you actually have a customized "out of memory" handler
> that indicates what exactly the offending line?
> Error checking is an attitude; it's not a feature of the language.

In Ada, it's both.

> 
> >
> >c) In this particular case (fiddling with machine level
> >representations) the most you can conclude from your "comment" is that
> >neither has an advantage over the other, i.e., for this _particular_
> >case, you claim that it's a wash.
> >
> >d) Even in HW interfacing there is a _lot_ more going on than the
> >actual machine level fiddling.  This work invariably requires
> >(implicitly or explicitly) higher level abstractions.
> >
> >e) No one is dumb enough to suggest C has high level abstraction
> >capabilities such as found in Ada.
> 
> On the contrary, C constitutes the low level base for Ada programs,
> the work horse, the "unsafe" layer (NT, UNIX, LINUX, etc...) without which
> it's impossible to build "safe" applications.

My Ada compiler generates object code, not C, and runs using an Ada
run-time
environment (also written in Ada). I build safety-critical applications
with it.
What Ada compiler are you using?

> The lack of high level abstraction
> doesn't hurt C a bit. C provides me with every component that made this post
> possible: the editor, the operating system, the networking software/firmware.
> I don't believe in C because everyone (well, almost) writes in C; I believe
> in C because it works just fine for me.

Do you build safety-critical applications?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Ada and robots

[Tom Moran]

>  How many of you actually have a customized "out of memory" handler
>  that indicates what exactly the offending line?
  The Janus compiler I use does.  Off the shelf, not cusomized.

Re: Ada and robots

[Huy Vo]

>Stephen Leake <Stephen.Leake@gsfc.nasa.gov>
>wrote
>Samuel Mize wrote:
>>
>> Note that I make some comments about the person Mr. Whiting quoted,
>> but none about Mr. Whiting.  Some quotations reformatted for length.
>>
>> Stephen Leake wrote:
>> >
>> > Matthew S. Whiting wrote:
>> >  ( second hand list of supposed Ada deficiencies )
>> ...
>> > > >*      Ada does not support discriminant unions (which are
>> ...
>> > This is precisely the Ada discriminant record:
>>
>> Ah, but you can't hand-code the discriminant values.  This makes it
>> harder to interface to existing C code, which of course makes C
>> fundamentally better.
>>
>Um, yes you can; that's what an enumeration representation clause is
>for; see RM13.4
>
>> Besides, you can't load the variable with one type and then read it
>> as another type.  In C it's simple and safe, while in Ada it requires
>> Unchecked_Conversion, which everyone knows is dangerous.
>
>Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
>it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)
>
Safe or not safe, it looks like Ada programs can crash on the field like
a previous poster admitted. The worse thing is that it leaves no trace
as to what leads to the crash.  And other posters have to come up with
ugly 'C hacks'  to provide traceback of Ada programs. There goes the myth
that Ada programs need no debugging.

Re: Ada and robots

[Jon S Anthony]

In article <199706201607.MAA01178@mermaid.ctron.com> Huy Vo <vo@CTRON.COM> writes:

> >Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
> >it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)
> >
> Safe or not safe, it looks like Ada programs can crash on the field like
> a previous poster admitted. The worse thing is that it leaves no trace
> as to what leads to the crash.  And other posters have to come up with
> ugly 'C hacks'  to provide traceback of Ada programs. There goes the myth
> that Ada programs need no debugging.

a) No one is dumb enough to suggest Ada programs are by nature some
how bug free.  So, you are just giving a silly strawman

b) Trace backs or not are _implementation_ dependent.  Plenty of C
implementations have nothing to offer here either (put together with
the fact that most have absolutely worthless compile time diagnostics
and you have something that basically offers zero support).

c) In this particular case (fiddling with machine level
representations) the most you can conclude from your "comment" is that
neither has an advantage over the other, i.e., for this _particular_
case, you claim that it's a wash.

d) Even in HW interfacing there is a _lot_ more going on than the
actual machine level fiddling.  This work invariably requires
(implicitly or explicitly) higher level abstractions.

e) No one is dumb enough to suggest C has high level abstraction
capabilities such as found in Ada.

f) Since a) & b) are irrelevant, c) is a wash and d) & e) favor Ada,
you would still have to claim a _general_ positive for Ada even under
your account.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[Jon S Anthony]

In article <Pine.SGI.3.95.970618125216.11737B-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> PS: I bought that book when it came out, in 1991. I was trying to use it 
> with SGI's version of CFront 3.0. Templates, nested classes (which are not 
> as useful as Java's inner classes) and exceptions were unusable then, and 
> still so several years thereafter. 

It is rather amazing, isn't it.  BTW, I've completely given up on C++.
I think C still has its uses, but C++?  I don't think so.

/Jon

-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[Brian Rogoff]

On 19 Jun 1997, Jon S Anthony wrote:
> > PS: I bought that book when it came out, in 1991. I was trying to use it 
> > with SGI's version of CFront 3.0. Templates, nested classes (which are not 
> > as useful as Java's inner classes) and exceptions were unusable then, and 
> > still so several years thereafter. 
> 
> It is rather amazing, isn't it.  BTW, I've completely given up on C++.
> I think C still has its uses, but C++?  I don't think so.

I do.

C++ is a very widely used *family-of-languages* which will be with us for 
a long time.  Certainly if I had my druthers, there would be little new C++
written and lots of new Ada (which I think is your point), but even in that 
better world there would be C++ written in the maintenance of existing
code. There is also a fairly large pool of C++ programmers out there, and a 
large number of projects cranking out code. So there probably is a use for 
C++ qua C++, even if we could make technical arguments that Ada can do the 
job "better".  

IMO, its really a question of degree only. All computer languages
fundamentally suck. I just happen to find Ada's flaws far more palatable 
for those programming tasks for which C, C++, and Fortran are often used.   

-- Brian

Re: ada and robots

[Jon S Anthony]

In article <Pine.SGI.3.95.970619163029.5827A-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> > It is rather amazing, isn't it.  BTW, I've completely given up on C++.
> > I think C still has its uses, but C++?  I don't think so.
> 
> I do.
> 
> C++ is a very widely used *family-of-languages* which will be with us for 
> a long time.

Oh, it is _used_ all over the place (well, more or less - it's often
difficult to glean whether it is just being used as a ANSI C sort of
thing.)  I was talking about "uses" as in "the best thing to use here
is C++".  This latter does not seem to have good rationale no matter
what the situation: if it is simply C stuff - use C.  Numerical stuff
- use Fortran.  If it is something needing flexible higher level
capabilities, sophistication and lower level efficiencies - use Ada
(or Eiffel).  Implemenations and availability are every bit as viable
as those for C++.  Something even higher level - use Lisp or ST or
some such.


> large number of projects cranking out code. So there probably is a
> use for C++ qua C++, even if we could make technical arguments that
> Ada can do the job "better".

I don't mean just "technically".


> IMO, its really a question of degree only. All computer languages
> fundamentally suck.

Right.  This I completely agree with.  However, a large enough
quantitative gap gives a qualitative difference.


> I just happen to find Ada's flaws far more palatable for those
> programming tasks for which C, C++, and Fortran are often used.

I hear ya.  But, for me, the degree to which C++ sucks puts it in a
class of its own.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[John G. Volan]

Brian Rogoff wrote:
> 
> On 19 Jun 1997, Jon S Anthony wrote:
> > BTW, I've completely given up on C++.
> > I think C still has its uses, but C++?  I don't think so.
> 
> I do.
> 
> C++ is a very widely used *family-of-languages*
                            ^^^^^^^^^^^^^^^^^^^^^

If this is really the case, then this is a serious problem with C++. 
The lack of a commonly-agreed upon standard that completely defines the
semantics of C++ as a _single_ language, with all available compilers
reliably implementing all of its features in comparable and compatible
ways, must be viewed as a major strike against it. (To be fair, such a
standard _is_ in the works, but the irony is that historians may
actually take the date of the final ISO vote of approval for the C++
standard as the official date of C++'s death as a fad, and its
replacement by the next fad, Java.) :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Richard A. O'Keefe]

"John G. Volan" <johnvolan@sprintmail.com> writes:
>Brian Rogoff wrote:
>> C++ is a very widely used *family-of-languages*

>If this is really the case, then this is a serious problem with C++. 

It is really the case.  For example, the <string> header, providing
C++'s equivalent of Ada.Strings.Unbounded (more or less), has been
in the draft standard since at least April 1995.  Of the two compilers
I have here, one supports it and one doesn't.  When I complained on
the net about this, the response from some C++ experts was "don't be
a whining idiot, use char*".  Of course, comparisons on 'char*' and
comparisons on 'string' do very different things...

In fairness to the compiler writers, C++ is an extremely complex language.
It's a pity neither of the compilers available to me supports 'namespace'
yet (which has also been in the draft standard since April 1995 at least),
but I'd much rather they got templates exactly right first.

-- 
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: ada and robots

[Robert Dewar]

Brian said

<<C++ is a very widely used *family-of-languages* which will be with us for
a long time.  Certainly if I had my druthers, there would be little new C++
<<



I don't understand the "family of languages" reference here.

Re: ada and robots

[Brian Rogoff]

On 23 Jun 1997, Robert Dewar wrote:
> Brian said
> 
> <<C++ is a very widely used *family-of-languages* which will be with us for
> a long time.  Certainly if I had my druthers, there would be little new C++
> <<
> 
> I don't understand the "family of languages" reference here.

Don't read too much into it. It is just a quip about the elusive nature 
of the meaning of "C++", inspired by years of working with it. I found 
that most C++ code I saw (late 80s and early 90s) really would have been 
best described as VC++, GNU C++, Zortech C++, etc, and these were all 
changing with each release (but not getting closer to each other). 

Yeah, you could argue that the same is true of Ada to some degree, but 
(as Jon pointed out) the quantitative difference is very great. Many 
articles by C++ cognoscenti in that time frame cautioned against the use 
of templates and exceptions in portable code, for example. 

-- Brian

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

Joe Gwinn <gwinn@RES.RAY.COM> writes:
>
>As for Ada83 experience, I have (or know of) both old and new experience,
>and most Ada83 compilers were very difficult to use for direct hardware
>control.  I suppose one could have made them work, but why would you?  If
>it's that hard, it won't be reliable.  We often reverted to assembly code
>for the machine control bits, long before C was a true option.  (We did
>the same when the base language was Fortran or Pascal, for the same
>reasons.)
>
    Again, I would ask for some real nice specific example of "here's
    a block of C code which does XYZ which Ada can't do - or can't do
    easily". I ask because I *have* been programming in Ada(83) for a
    long time, right down to controlling very specific hardware and
    never once did I consider it any harder than in any other
    language. (Often easier, in many cases.) And BTW, *reliability* is
    probably *THE MOST IMPORTANT* concern in producing a control
    computer for a jet or rocket engine. My experience has told me
    that it is neither difficult, nor unreliable - depending, of
    course, on exactly how you go about it. (Anybody can make things
    difficult and unreliable in any language of choice by trying to do
    things the hard way or by bad design.)

>
>As for Ada83 and shared memory, the problem was that the Ada83 compilers
>all believed that only they changed memory, so it was OK to cache data
>items in CPU registers for long periods of time.  For the most part, there
>was no reliable (and portable) way to tell the compiler different, so we
>performed various dances to ensure that Ada83 never knew the whole truth.
>
    Ahhhhhh! *Now* I understand what the complaint about shared memory
    is all about. Ada83 provided "pragma SHARED" which would handle
    this, sort of. The semantics of this pragma were a little overly
    restrictive if all you wanted to do was force the compiler not to
    optimize the storage into a register. (So a solution did exist,
    but not necessarly the best possible solution.) Our compiler
    vendors typically supplied us with a "pragma VOLATILE" (which I
    think is now standard in Ada95) which told the compiler not to
    optimize the value in a register. It worked pretty much as
    expected and we've got no complaints.

    BTW: What exactly does C provide to keep this from happening? I
    don't recall it ever being something defined in "standard" C - and
    why should it be? "Standard" C never defined any sort of
    multi-tasking and so never needed any sort of mechanism to tell
    the compiler that a variable should not be retained in a register.
    Is there some sort of mechanism to do this? (I recall it had the
    ability to tell the compiler you would *like* to have a given
    variable allocated to a register - and maybe it did and maybe it
    didn't. But I don't recall any way of saying "don't allocate this
    to a register behind my back, please.")

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."

        --  Everett Dirksen
===============================================================================

Re: ada and robots

[Joe Gwinn]

In article <97061611223212@psavax.pwfl.com>, "Marin David Condic,
561.796.8997, M/S 731-93" <condicma@PWFL.COM> wrote:

> Joe Gwinn <gwinn@RES.RAY.COM> writes:

> >As for Ada83 and shared memory, the problem was that the Ada83 compilers
> >all believed that only they changed memory, so it was OK to cache data
> >items in CPU registers for long periods of time.  For the most part, there
> >was no reliable (and portable) way to tell the compiler different, so we
> >performed various dances to ensure that Ada83 never knew the whole truth.
> >
>     Ahhhhhh! *Now* I understand what the complaint about shared memory
>     is all about. Ada83 provided "pragma SHARED" which would handle
>     this, sort of. The semantics of this pragma were a little overly
>     restrictive if all you wanted to do was force the compiler not to
>     optimize the storage into a register. (So a solution did exist,
>     but not necessarly the best possible solution.) Our compiler
>     vendors typically supplied us with a "pragma VOLATILE" (which I
>     think is now standard in Ada95) which told the compiler not to
>     optimize the value in a register. It worked pretty much as
>     expected and we've got no complaints.

"Sort of" is exactly right; neither correct nor consistent from compiler
to compiler.  Some compilers also provided pragma volatile, but
implementations varied, and some were deeply unclear on the concept of
volatile, so we couldn't use either shared or volatile.


>     BTW: What exactly does C provide to keep this from happening? I
>     don't recall it ever being something defined in "standard" C - and
>     why should it be? "Standard" C never defined any sort of
>     multi-tasking and so never needed any sort of mechanism to tell
>     the compiler that a variable should not be retained in a register.
>     Is there some sort of mechanism to do this? (I recall it had the
>     ability to tell the compiler you would *like* to have a given
>     variable allocated to a register - and maybe it did and maybe it
>     didn't. But I don't recall any way of saying "don't allocate this
>     to a register behind my back, please.").

All C compilers provide the "volatile" attribute, which one can apply to a
(static) variable, and I've never heard of a C compiler that got it wrong
surviving for long.  I don't recall if volatile is in Kernigan and Richie,
but it's probably in ANSI C.  I think I'll look it up.


We also had problems with different compilers handling generics
differently, especially with respect to the allowed nesting depth.

I believe these problems are fixed in the Ada95 standard, and should be
fixed in the Ada95 compilers.

Joe Gwinn

Re: ada and robots

[Jon S Anthony]

In article <gwinn-1706972242370001@dh5055155.res.ray.com> gwinn@res.ray.com (Joe Gwinn) writes:

> "Sort of" is exactly right; neither correct nor consistent from compiler
> to compiler.  Some compilers also provided pragma volatile, but

But this is all out of date.

> We also had problems with different compilers handling generics
> differently, especially with respect to the allowed nesting depth.

Again - not relevant at this point.  Actually it probably _is_
relevant only it now applies - IN SPADES - to C++ templates.


> I believe these problems are fixed in the Ada95 standard, and should be
> fixed in the Ada95 compilers.

Correct.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[Brian Rogoff]

On 18 Jun 1997, Jon S Anthony wrote:
> In article <gwinn-1706972242370001@dh5055155.res.ray.com> gwinn@res.ray.com (Joe Gwinn) writes:
> > We also had problems with different compilers handling generics
> > differently, especially with respect to the allowed nesting depth.
> 
> Again - not relevant at this point.  Actually it probably _is_
> relevant only it now applies - IN SPADES - to C++ templates.

What Jon, you've been having problems using C++ templates? Why, they are 
a relatively new feature of the language, having only been described in 
Lippman's C++ Primer 2ed. :-)

PS: I bought that book when it came out, in 1991. I was trying to use it 
with SGI's version of CFront 3.0. Templates, nested classes (which are not 
as useful as Java's inner classes) and exceptions were unusable then, and 
still so several years thereafter. 

-- Brian

Re: ada and robots

[Robert Dewar]

Joe said

<<"Sort of" is exactly right; neither correct nor consistent from compiler
to compiler.  Some compilers also provided pragma volatile, but
implementations varied, and some were deeply unclear on the concept of
volatile, so we couldn't use either shared or volatile.
>>


pragma Shared is well defined in the Ada 83 standard, and was correctly
implemented on all Ada 83 compilers that I have used. I can believe that
it is possible that Joe's group chose an ill-suited compiler that did not
get this important feature right (I have known plenty of C compilers get
things wrong -- and indeed know of one case in which a C compiler got
volatile seriously wrong).

However, the fact that I know a C compiler that did volatile wrong does not
make me say either of

  (a) C is useless for memory mapped IO
  (b) the volatile feature in C is useless because it is not implemented
	right on one compiler.

But that appears to be the dubious logic being used in this case for Ada.

Actually neither C nor Ada can guarantee to get memory mapped I/O "right"
at the language level, since the required semantics are of necessity at
the machine language level, and whether or not a given sequence in C or
Ada works is definitely bound to be implementation dependent. Yes, usually
in Ada (and C), doing the obvious thing works fine, and people often depend
on it, but it is a somewhat risky approach.

Let me give an example.

One customer of ours ported a large code from VADS to GNAT, and it did not work.
A huge amount of digging yielded the following "bug" report.

   type Bits is array (natural range <>) of Boolean;
   pragma pack (Bits);

   Bitvar : Bits (0 .. 31);
  
   ...

   Bitvar (17) := 1;

Now first, there is no guarantee of the order in which bits in such a packed
array are ordered, but there is a natural ordering, which both VADS and GNAT
followed (based on the endianness of the machine), so that was not a problem.

But the problem was that Bitvar had an address clause

  for Bitvar use at ...

which mapped it into the address space of some custom build hardware.

This hardware accepted ONLY word (4-byte) memory requests, and simply
malfunctioned in a completely unpredictable manner if byte memory requests
were received.

You guessed it, VADS used a loadword/or/storeword sequence, and GNAT used
a loadbyte/or/storebyte sequence.

Now there is nothing to say one of these is better than the other, they simply
represent two equally good ways of doing things.

The fix turned out to be simple, by changing the code to

  type Bits is array (0..31) of Boolean;

GNAT could be persuaded to generate the word sequence.

But there code was always relying in an undocumented way on the particular
choice of the compiler, and for that matter, still is.

Also, there is nothing really language independent here. Corresponding C
code would be equally subject to varying possible compilatoin possibilities.

For my taste, I rarely like the idea of using address clauses or the 
corresponding casts in C for this purpose. I would prefer to write two
small inlined routines that used machine language insertions to generate
EXACTLY the instructions that the IO hardware requires.

Re: ada and robots

[Richard Kenner]

In article <dewar.866846641@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>For my taste, I rarely like the idea of using address clauses or the 
>corresponding casts in C for this purpose.

This is perhaps a case where the casts in C are more portable.

If you write

	* ((volatile long *) some_address) |= some_expression;

it would be quite peculiar (and perhaps even be considered a bug) if the
compiler didn't respect the "long" type and generate the correspondingly
sized load and store instructions.

Re: ada and robots

[Robert Dewar]

Richard said

<<This is perhaps a case where the casts in C are more portable.

If you write

        * ((volatile long *) some_address) |= some_expression;

it would be quite peculiar (and perhaps even be considered a bug) if the
compiler didn't respect the "long" type and generate the correspondingly
sized load and store instructions.
>>

I don't see this claim at all. The corresponding Ada code would be
identical semantically to the C code, and the same statement ("quite
peculiar .. perhaps even be considered a bug") would apply to the Ada.

But that was not the example, the example was where a single bit was flipped.

If we write   x &= 1;

in C where x is a volatile variable, there is nothing in the C language
that indicates whether we get

word load/store
byte load/store
bit set instruction (quite reasonable to expect on x86)


I think that the semantics of Ada and C are identical here. The advantage
of Ada is that it is a little more clear that you are playing low level
games -- in particular the quoted C code, in which the volatility is buried
in low level implementation, is undesirable.

Re: ada and robots

[Geert Bosch]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
 ``This hardware accepted ONLY word (4-byte) memory requests, and
   simply malfunctioned in a completely unpredictable manner if
   byte memory requests were received.
   [...]
   The fix turned out to be simple, by changing the code to

     type Bits is array (0..31) of Boolean;

   GNAT could be persuaded to generate the word sequence.  But
   there code was always relying in an undocumented way on the
   particular choice of the compiler, and for that matter, still is. ''

IMO it is an obvious bug to do memory I/O to such a device using
an unconstrained array type without any representation clauses or
whatever. From such a device you should only read data with 'Size=32
and pragma Atomic applied:
   type Bits is array (0 .. 31) of Boolean;
   pragma Pack (Bits);
   pragma Atomic (Bits);
   for Bits'Size use 32;

Certainly I would not expect any compiler to read elements from
Bits using byte reads in this case. For larger bit arrays than 32
bits I would choose to map the entire device memory using a
constrained array of Bits, like:
   type Word_Index is range 0 .. 2**32 - 1;
   type Words is array (Word_Index range <>) of Bits;
   subtype Video_Words is array (0 .. 16#3FFF#);

Of course this can only guarantee 32-bits memory-mapped I/O on a 
machine with a 32-bit I/O bus. 

A much harder problem is to ensure only byte-reads. I agree with
Robert that in cases like this the only good solution is to use
machine code insertions, since there is no way in Ada to forbid a
compiler to read several array elements at a time.

It would seem natural for the compiler to use memory reads of exactly
Component_Size if supported by the hardware and pragma Atomic_Components
is specified for the type, but counting on it is dangerous.

Regards,
   Geert

Re: ada and robots

[Robert Dewar]

iGeert said

<<IMO it is an obvious bug to do memory I/O to such a device using
an unconstrained array type without any representation clauses or
whatever. From such a device you should only read data with 'Size=32
and pragma Atomic applied:
   type Bits is array (0 .. 31) of Boolean;
   pragma Pack (Bits);
   pragma Atomic (Bits);
   for Bits'Size use 32;

Certainly I would not expect any compiler to read elements from
Bits using byte reads in this case. For larger bit arrays than 32
bits I would choose to map the entire device memory using a
constrained array of Bits, like:
   type Word_Index is range 0 .. 2**32 - 1;
   type Words is array (Word_Index range <>) of Bits;
   subtype Video_Words is array (0 .. 16#3FFF#);
>>



Of course the code had the pragma Pack. I thought that was obvious
from context.

The Size clause is totally redundant, people often put it in for
good measure, but it has no effect, except to confirm the choice
that the compiler is making anyway.

The pramga Atomic is completely irrelevant, it affects only the semantics
of reads and writes to the entire array, not to its components.

<<Certainly I would not expect any compiler to read elements from
Bits using byte reads in this case>>

Yes, well the programmers in this case agreed with you. Unfortunately
you have absolutely NO basis for this expectation whatsoever. If you
think otherwise, try to prove it from the RM.

On some machines, the word read will be faster than the byte read

On some machines the byte read will be faster than the word read
(the 386SX is an example)

Om most machines, the speeds will be the same

For the first case, one hopes, but cannot be sure, that the compiler
will do word reads.

For the second case, one hopes, but cannot be sure, that the compiler
will do byte reads.

For the third case, one should have no hopes or expectations whatever!

It is these unjustified "Certainly I would not expect" intutions that
have no basis in the language definitoin that end up causing trouble!

Re: ada and robots

[Jonathan Guthrie]

In comp.lang.ada Joe Gwinn <gwinn@res.ray.com> wrote:

> All C compilers provide the "volatile" attribute, which one can apply to a
> (static) variable, and I've never heard of a C compiler that got it wrong
> surviving for long.  I don't recall if volatile is in Kernigan and Richie,
> but it's probably in ANSI C.  I think I'll look it up.

"volatile" is ANSI, not K&R.

Support for "volatile" was badly broken (along with the file buffering,
and possibly other things) in Borland's Turbo C 2.0.  That compiler
survives even unto today.

Well, okay, it's been updated.  I suspect that "volatile" has been
fixed, but I also suspect that buffered files have not.  (They don't
not work, they just don't work the way any reasonable human being
would expect.  Email me if you'd like details.)

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

Re: ada and robots

[Will Rose]

Joe Gwinn (gwinn@res.ray.com) wrote:
[...]
: All C compilers provide the "volatile" attribute, which one can apply to a
: (static) variable, and I've never heard of a C compiler that got it wrong
: surviving for long.  I don't recall if volatile is in Kernigan and Richie,
: but it's probably in ANSI C.  I think I'll look it up.

Volatile is strictly ANSI - I think it may even have been backformed
from C++.  An ANSI compiler will reserve it, and a conformant ANSI
compiler will implement it correctly...

Will (not cynical at all, no, no, why would you think that?)
cwr@crash.cts.com

Re: ada and robots

[Nick Roberts]

Marin David Condic, 561.796.8997, M/S 731-93 <condicma@PWFL.COM> wrote in
article <97061611223212@psavax.pwfl.com>...
[...]
>     BTW: What exactly does C provide to keep this from happening? I
>     don't recall it ever being something defined in "standard" C - and
>     why should it be? "Standard" C never defined any sort of
>     multi-tasking and so never needed any sort of mechanism to tell
>     the compiler that a variable should not be retained in a register.
>     Is there some sort of mechanism to do this? (I recall it had the
>     ability to tell the compiler you would *like* to have a given
>     variable allocated to a register - and maybe it did and maybe it
>     didn't. But I don't recall any way of saying "don't allocate this
>     to a register behind my back, please.")


ANSI C provides the type modifier 'volatile' for this purpose. Is this what
you were asking?

Nick.

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

>OBAda: I have some (small) sympathy with Joe Gwinn's position that some
>combinations of Ada83 compilers may have produced very different
>results. Imagine that you used a generic-sharing compiler orginally for a
>memory limited system, and then tried to port that code to a similar target
>that used expansion instead. Or tasking that mapped tasks to OS processes
>vs. run-time scheduling (and you want to do blocking IO in the tasks.)  One
>of the phrases I remember least fondly when trying to explain why some
>particular code was ill suited to a particular embedded
>compiler/runtime/target.
>        "But it runs just fine on our Vax using DEC Ada!"
>
    This may well be true, but I don't know how it could possibly be
    avoided. Whenever a language specifies a feature beyond a certain
    complexity, you're going to get a variety of different
    implementations which have inherent portability limits (especially
    in real-time where memory and/or time are limited resources.)

    For example: If Ada and C both specify some basic mathematical
    capability (C++ vs Integer'Succ(C)) you'd expect both statements
    to consume nearly the same amount of space/time on virtually any
    implementation (target hardware remaining the same). But the
    minute a language gives you something like "accept X do...", you
    can expect semantic behavior to be consistent, but space/time is
    going to be entirely dependent on what sort of tasking model
    underlies the support for the accept statement.

    I guess you could say that C solves the problem by never giving
    you anything very complex to use. So if you need the complex
    features, you've got to "roll your own" and in some cases this is
    going to be difficult to near impossible.

    I'd fault a compiler vendor for not selling semantically correct
    behavior, but I couldn't fault the vendor or the language just
    because a given feature may have multiple possible
    implementations, each with their own advantages and drawbacks.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."

        --  Everett Dirksen
===============================================================================

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

Joe Gwinn <gwinn@RES.RAY.COM> writes:
>There is tons of such code available for free on the internet.  Just look
>for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
>Packages are another example.
>
>Even C-coded I/O drivers and kernel initialization sequences resort to
>some assembly code.
>
>As for shared memory, look into the handling of driver comm pools, queues
>shared between tasks and also with ISRs.  And so on.
>
>For UNIX drivers, there are multiple books available on exactly how to
>write such drivers, all in C.  Most include (annotated) sample driver
>code.
>
>I would submit that there is ample evidence that C can be used for direct
>hardware control, and for shared memory.
>
>I would not claim that all who have tried such things have succeeded,
>regardless of language.  Many programmers couldn't write an I/O driver if
>their life depended on it.
>
    It seems that what your saying is that C has been used to develop
    code which exercises direct control of hardware and is able to
    implement shared memory data structures between threads. I don't
    think that anyone would doubt this.

    I think what I originally took exception to was the claim that Ada
    *can't* do these things. If I was trying to implement some
    extension to Unix, (a device driver, perhaps) I probably wouldn't
    spit into the wind by trying to do it in Ada (Given that the whole
    OS is written in C, all the support tools are C oriented and I
    wouldn't want to maintain one lonely little Ada module afloat in a
    Sea of C ;-) But that's a far cry from claiming that Ada is
    incapable of being used to write device drivers.

    I've written lots of code which implements interfaces to A/D
    converters, ISR's, discrete I/O, Mil-Std-1553 buses, UARTs,
    Manchester data links, etc, etc, etc. All in Ada(83). I've shared
    memory between tasks and between processors using Ada(83) (albeit,
    not using the "pragma SHARED" - but implementing what you'd have
    to do for yourself in C anyway - a semaphore or some hardware
    support for shared memory.). So it's a little hard to read "Ada
    can't be used down at the bare metal" when you know that you've
    been doing just that for years - and that it's not at all
    any more difficult than it would be in C.

    While I won't presume to speak for Dr. Dewar (I know he's pretty
    good at clarifying himself :-) I think its fair to say we'd both
    like to see an example of something you believe that C does in
    dealing with the bare machine that you feel would be difficult in
    Ada. I'll accept that there may be some things C does better than
    Ada, but I'd like to see an example.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."

        --  Everett Dirksen
===============================================================================

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

dana@INDYWEB.NET writes:
>      A:  No, or at least not many.  It's hard to put an exact reason as
>to why but it is thought that these MCs are just "too small" in terms of
>address space etc to support a multitasking language/runtime.  Hello world
>generated by DDCI's sun cross 80386EX compiler is JUST under 16k with the
>non-tasking runtime.  I've seen similar performance from other Ada
>compilers.  The whole answer is much longer but has been discussed at
>length in this group.  Now, that being said, it is still worth a check of
>adahome to see what the vendors have.  I could be wrong.  It wouldn't be
>the first time:-)
>
    I've found a few microcontroller vendors out on the web which seem
    to have products that might fit the bill: Z-World
    (http://www.zworld.com/) who makes a Z180 based system, Micronix
    (http://www.agt.net/public/micronix/) with a 68HC11 based system
    and Claritech (http://www.claritech.demon.co.uk/) with a SH7032
    and a 68032 based system. All appear to have a C development
    environment available and all appear to be reasonably priced. It
    would seem to be cost effective to go this sort of route rather
    than trying to cobble together your own development system even if
    you could find an Ada compiler targeted to one of these chips.
    (Getting the generated code is only *part* of the problem. You've
    still got to get it loaded into the box, working with some
    reasonable monitor system, outputting symbols for a cross-platform
    debugger, etc, etc, etc. Do you *really* want to spend time doing
    that when you can buy the whole ball of wax for under $200?)

    Modern Ada compilers and modern microprocessors should not impose
    any inherent barriers because of space. We managed to get a whole
    rocket engine control system into 48k words on a Mil-Std-1750a
    microprocessor. Most of these microcontrollers will give you five
    times that space right off the shelf. Older compilers did indeed
    have a problem with space, largely due to tasking support. But I
    am informed by people who should know (as well as practical
    experience) that this is a problem of the past.

>2)    Q:  Is Ada used in robotics?  This is a question several occasional
>posters to this group could have answered.  But the answers weren't
>exactly what the original poster was looking for.  Robotics is a vary
>broad field ranging from little critters skittering about on the floor
>with 8 bit micro controllers to large kinematically redundant manipulator
>mechanisms with multiple 32 bit high performance processors.
>
    To the extent that engine controls apply lots of the same
    principles used in robotics (feedback loops, etc to control the
    motion of actuators) I can testify that Ada is indeed adequate in
    and of itself to do the job. And in that sense, it is used quite
    extensively in this sort of "robotics" application. The problem is
    not so much one of "is the language suitable?" or "is the language
    used in this domain?" as it is one of "is the language available
    for the target I have in mind?"

    You're on target with the notion that there is no single correct
    answer in language selection for all projects. I believe Ada has
    lots of technical merit over other choices, but technical merit
    isn't the only selection parameter.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."

        --  G.K. Chesterton
===============================================================================

Re: ada and robots

[Marin David Condic, 561.796.8997, M/S 731-93]

Dale Stanbrough <dale@GOANNA.CS.RMIT.EDU.AU> writes:
>"small systems a student can afford"
>        The Meridian Ada compiler, which comes for free with a book, is rather
>        cheap, and targets any of the 8086 family (which are cheap, no?).
>        It is Ada83 however. So I think you agree with you.
>
    Before I start my tirade, let me preface by saying that I *like*
    Ada and prefer Ada to C. I 'reach', I'm 'of the body', Resistance
    was futile: I have been absorbed, I am part of The Borg, etc. But
    that doesn't mean there aren't some valid criticisms of Ada or
    times when C is more appropriate.

    I believe when the original poster was discussing this issue, it
    was about small, inexpensive microcontrollers for robotics. I've
    looked at a number of such computers (stuff that can be had for
    between $80 and $200, including development software {read: C
    compiler, loading & debugging tools}). An 8086 running some
    version of real-time MS-DOS (plus cobbling together your own
    cross-compilation environment) may be overkill, may not provide
    the analog & discrete I/O hardware support needed and would
    probably require non-trivial effort to get the Meridian Ada
    compiler, etc. set up to produce/load/debug code in the SBC.

    I imagine one could spend money/time retargeting GNAT to some SBC
    & get it up and running with the RTEMS real-time OS and cobble
    yourself together everything you need to load/debug images. Or you
    could buy the little microcontroller for $200 and get an
    integrated development environment using a C compiler. It doesn't
    take a rocket scientist to figure this one out. {But if it did, I
    just so happen to be one!}

    The embedded microcontroller market seems to have been conceeded
    to C for the time being and, especially for student projects,
    small development jobs and quick&dirty fixes, I'd recommend not
    spitting into the wind. (You certainly can't argue that life cycle
    costs are going to recoup me the $100k+ cost of building the
    port!) And this is *one* area where I'd desperately like to be
    proven wrong - if you want to show me a small (~3" x 5") SBC with
    analog & discrete connections, programmable from a serial port on
    a PC with an integrated development environment including an Ada95
    compiler for around $200, I'll gladly admit I'm wrong.

    As for the rest of the criticisms you addressed, I think you're
    right on target.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
West Palm Beach, FL                             Internet:   CONDICMA@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."

        --  G.K. Chesterton
===============================================================================

ada and robots

[John Bohn]

I am an Ada student. I have heard that Ada was designed for embeded
systems, but I haven't heard much about micro controller ada
programming. 

Does anyone know about any examples of the usage of Ada for robots
and programming micro controllers?

Thank you very much
John Bohn

Re: ada and robots

[Stephen Leake]

The NASA Space Station project was using Ada to write a robot control
system; we got one working in the lab that did some good demos, but then
the project was cancelled. We used Ada 83, targeting bare Intel 386 in a
Multibus. I was VERY glad we were using Ada; it gave precise control
over low-level bits, and at the same time enforced high-level
interfaces.

JPL did some Ada robotics, but then they switched to C++ and TCL/TKL.

You can see some of my Ada code for Robotics from my web page:

http://www710.gsfc.nasa.gov/~sal714/homepage.html

-- 
- Stephe

Re: ada and robots

[Michael F Brenner]

The Ada language has the required features for programming controllers:
low level bit operations, absolute memory addressing, interface to 
assembler code, interrupt handling, etc. It also has a number of features
not required, but helpful for programming controllers: the best bug
catching at compile time, some of the best encapsulation, the ability
to express many algorithms without bug-prone pointers, good optimization,
ability to do tasking, etc. In a toy robot, the controllers do not need
much programming, usually an external scheduling computer does the
dynamics and kinematics, resulting in a set of curves that the controller
follows, programmed in an ASIC or a PROM as numbers with a very tiny
program to put those numbers into a memory mapped board register, and
the hardware does the rest. In autonomous robots, however, where each
tick of the clock requires computation a Kaman array of Kalman filters,
adjustment of the boundaries in a Voronoi diagram, and reclustering
of the distance and force matrix between obstacles, the controller
of a joint looks a lot more like a complex general-purpose computer
with specially designed I/O circuits. In the first case, the toy
robot, it does not matter which language you use because there are
so few actual instructions required, if the whole thing is table-driven,
or else the instructions are boiler-plate macros stamped out by some
finite state machines, where, again, source language is irrelevant,
they are just a bunch of gotos mixed with set-port commands at the machine
code level. In the second case, the sophisticated bug control and
packaging features of Ada can help develop the code faster than other
languages, regardless of whether Ada is the target language; that is, 
after developing in Ada, if you find that the code is mostly just a
bunch of FSAs anyway, you can stamp them out as boiler plate assembler code,
using those same FSAs with a different action matrix, and use that
assembler code as the target. However, in an autonomous robot, Ada might
be the best language for the final target as well.

Re: ada and robots

[John Cook]

John Bohn wrote:
> 
> I am an Ada student. I have heard that Ada was designed for embeded
> systems, but I haven't heard much about micro controller ada
> programming.
> 
> Does anyone know about any examples of the usage of Ada for robots
> and programming micro controllers?
> 
> Thank you very much
> John Bohn


If you like ADA, that is, if you enjoy very very verbose code and a very
limited set of vendors then ADA is OK.  

However, if you want a small, terse language that is easily expandable,
has been proven for 30 years and has a huge set of vendors that target
the type of small systems a student can afford, look into C language. 
I'll admit that its harder to read than ADA but K&R wanted a portable
assembly language with a rich set of operators  and minimal constraints
so they invented C, and it works.  (And everyone uses it, unlike ADA).

just my $0.02

-John C.-**
-- 
Founder of Nashua Robot Builders, small computer/robot club in Nashua,
NH
jdcook@tiac.net 
http://www.tiac.net/users/bigqueue/others/robot/homepage.htm
Member of the national lawsuit to repeal the Communications Decency Act.
Happy ferret owner.

Re: ada and robots

[Tom Moran]

> K&R wanted a portable
> assembly language with a rich set of operators  and minimal constraints
> so they invented C
  How many people still use K&R C?  Would you call C++ a portable
assembly language?

Re: ada and robots

[Dale Stanbrough]

John Cook writes:

"If you like ADA, that is, if you enjoy very very verbose code and a very
 limited set of vendors then ADA is OK.  
 
 However, if you want a small, terse language that is easily expandable,
 has been proven for 30 years and has a huge set of vendors that target
 the type of small systems a student can afford, look into C language. 
 I'll admit that its harder to read than ADA but K&R wanted a portable
 assembly language with a rich set of operators  and minimal constraints
 so they invented C, and it works.  (And everyone uses it, unlike ADA)."


The level of Usenet debate never ceases to amaze me (or maybe it's just
debate in general).

Lots of claims made about C, and many inferences that similar capabilities
in Ada are not available.
Lets look at them...

"small terse language"
	agree

"easily expandable"
	perhaps, but it seems that small systems restrict rather than expand
	facilities. I wonder what features you are thinking of.

"proven for 30 years"
	So it has was written well before 1967, and has been _proven_ in the
	30 years hence? (I don't regard the first year of tinkering with a 
	language as proving it!). I always thought it was written in the '70's.
	Note that C proving itself has led to the introduction of constants,
	references, namespaces, prototypes etc etc etc. in recent years.

"huge set of vendors"
	Could well be. It's certainly easier for people to write a compiler
	for than Ada. Still what counts is is there a compiler/tools company
	for the stuff you are interested in.

"small systems a student can afford"
	The Meridian Ada compiler, which comes for free with a book, is rather
	cheap, and targets any of the 8086 family (which are cheap, no?).
	It is Ada83 however. So I think you agree with you.

"its harder to read than ADA"
	I think i'ld agree for most things (for arrays of ragged strings C is
	much easier to read, also there is a dichotomy b/w simple {} and the 
	named construct/end construct in terms of readability).

"but K&R wanted..."
	But? This is the strangest claim of all. Why is readability
	inimical to a portable assembly language (which i don't think C is)?
	You could easily change the reserverd words etc, and provide
	references a'la C++, which would dramatically improve it's
	readability.

"a rich set of operators"
	...and by implication Ada does not have. Maybe it doesn't have the
	same set of operators per se (such as "<<", ">>" etc), but it
	certainly has equivalent functionality, which is what really counts
	(functions shift_left, shift_right)

"minimal constraints"
	...and by implication Ada does not have. I'm not really sure what
	you are on about here. What feature does C have that Ada doesn't?

"and it works"
	...and by implication Ada doesn't. What a funny thing to say. In
	what way doesn't it work technically?

"(And everyone uses it, unlike ADA)"
	Well it don't think _everyone_ uses it. I agree with you that not
	everyone uses Ada, but universal quantification has always been  a
	rather heavy claim to support.


Whew!

Dale

Re: ada and robots

[John G. Volan]

Dale Stanbrough wrote:
> 
> John Cook writes:
> 
> "small systems a student can afford"
>         The Meridian Ada compiler, which comes for free with a book, is rather
>         cheap, and targets any of the 8086 family (which are cheap, no?).
>         It is Ada83 however. So I think you agree with you.

Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
it does let you write standalone Mac apps in Ada.)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Martin A. Stembel]

Jesse Johnson wrote:
> 
> I came into this thread late, so I'm sorry if this has already been
> said.  Ada was designed by the DOD as a systems programming language
> for embedded systems in military vehicles, while C was designed as an
> application programming language to be run on top of systems.  This

I always thought K&R came up with C for systems programming...Unix comes
to mind...

> makes Ada inherently better suited for robot programming.  However,

Well now, that all depends on the characteristics of OS/Kernel on which
your run-time was implemented.  Ada on SCO Unix would definately not be
inherently better suited for closing a position loop than another
language running on OS-9 or LynxOS.  All other things being equal, I'ld
probably choose Ada because I have more experience with it.  Generally
though, I've found that a good programmer can write quality code in any
language, and the bad ones will muck things up no matter how much the
language tries to hold their hand.

> for someone like me who has done a number of years of application
> programming and is now trying robotics, it's easier to use C because I
> already know it.
> 
>                         Jesse Johnson
>                         jejo@empireone.net

Re: ada and robots

[Joe Gwinn]

In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson) wrote:

> Ada was designed by the DOD as a systems programming language
> for embedded systems in military vehicles, while C was designed as an
> application programming language to be run on top of systems.  This
> makes Ada inherently better suited for robot programming.  However,
> for someone like me who has done a number of years of application
> programming and is now trying robotics, it's easier to use C because I
> already know it.

Umm, C was written as a systems (that is, operating systems) programming
language, riding right on the metal.  The comparison was assembly code.  C
was intended to be in effect a machine-independent assembly language, so
that an OS (UNIX) written in C would be portable from platform to
platform.  

Read the Introduction section of K&R to get the short history and original
intent of C.  For a non-Ada comparison, read the Introduction section on
page 133 of the "Pascal User Manual and Report", 2nd ed, Jensen and Wirth,
Springer-Verlag 1974.  Recall that Pascal was the base language upon which
Ada was based.  Reading these side by side is quite illuminating.

So, one cannot conclude on the basis of original intent alone that Ada is
more suited to robot programming, as both were intended from the start to
ride the metal.  

In practice, C was much more successful than Ada83 at riding metal. 
Experience with Ada83 shows that it is very bad at direct control of
hardware, especially I/O hardware, and simply does not handle shared
memory correctly.  Ada95 is claimed to be better, but I don't have any
direct experience with it.  Actually, not many people do just yet.  I
suspect that most people are using C (perhaps called from Ada) for direct
control of I/O hardware and the like.

Most "Ada systems" I have seen built recently are actually mixed-language
systems, being a mix of C, C++, and Ada, with the Ada being in the
minority (maybe 25%), if one counts all the purchased COTS code in the
system.  Typically, the operating system, middleware, and GUI stuff are
all in C, and the application code is mostly in Ada (with C bindings, and
no Ada runtime).

Not all Ada compilers offer adequate support for such mixed-language
systems, especially when it comes time to debug on target (vice host)
systems.  This can be a severe problem, because it's generally impossible
to build a competitive offering without extensive use of COTS components,
which are almost always in C/C++, and impossible to get working soon
enough to matter without good debugging support.  Whatever set of
compilers and tools you plan to use should be demonstrated to do *exactly*
what you need done, with sufficient performance, before purchase.  Don't
assume that anything works until proven.  (A year ago, we very nearly
bought an Ada that couldn't even link a mixed-language (C and Ada83)
VxWorks system, let alone execute the code and debug.  Insisting on a true
and accurate demo saved our butts.)

I would also comment that DoD's recent recinding of the Ada Mandate will
likely cause the Ada compiler and tools market to shrink to perhaps as
little as one tenth of its prior size, and that significant added
investment in Ada compilers and tools is therefore unlikely, at least
until the size of the remaining market becomes clear.  A significant
shrink is widely expected because the many DoD customers who chose Ada
because of the mandate will now immediately vanish, and DoD's big push
towards COTS is in effect a push to C/C++.  The Ada market used to be at
most one tenth the size of the C market, and things took forever to get to
the Ada world.  Now, it will be one hundredth.  So, if something Ada is
not in hand today, don't wait.  It could be a long time coming.  

Joe Gwinn

Re: ada and robots

[Pat Rogers]

Joe Gwinn <gwinn@res.ray.com> wrote in article
<gwinn-0306971836410001@smc19.ed.ray.com>...
> In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson)
wrote:
[snip]

> In practice, C was much more successful than Ada83 at riding metal. 
> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.  Ada95 is claimed to be better, but I don't have any
> direct experience with it.  Actually, not many people do just yet.  I
> suspect that most people are using C (perhaps called from Ada) for direct
> control of I/O hardware and the like.

Your "experience" may be as indicated (you don't say whose) but mine has
been different.  In my experience Ada has been very good at control of
hardware.  I can't imagine what you are talking about with respect to not
handling shared memory correctly.  I've done it gleefully in both versions
of the language, thanks very much.  Is it perfect? Of course not.  What
programming language is?  Certainly not C, including "riding the metal".

> 
> Most "Ada systems" I have seen built recently are actually mixed-language
> systems, being a mix of C, C++, and Ada, with the Ada being in the
> minority (maybe 25%), if one counts all the purchased COTS code in the
> system.  Typically, the operating system, middleware, and GUI stuff are
> all in C, and the application code is mostly in Ada (with C bindings, and
> no Ada runtime).

No run-time, huh.  That would be interesting to see.

[snip]

> I would also comment that DoD's recent recinding of the Ada Mandate will
> likely cause the Ada compiler and tools market to shrink to perhaps as
> little as one tenth of its prior size, and that significant added
> investment in Ada compilers and tools is therefore unlikely, at least
> until the size of the remaining market becomes clear.  

The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
-- it will follow the board's recommendation to fund the $15 million for
infrastructure.

I believe you when you say that you are out of date (at the top of your
post) with respect to Ada.

Re: ada and robots

[Joe Gwinn]

In article <01bc7132$11100fa0$4c0b6dce@my-pc.neosoft.com>, "Pat Rogers"
<progers@acm.org> wrote:

> Joe Gwinn <gwinn@res.ray.com> wrote in article
> <gwinn-0306971836410001@smc19.ed.ray.com>...
> > In article <5mv984$7kn@news.emi.com>, jejo@empireone.net (Jesse Johnson)
> wrote:
> [snip]

> > Most "Ada systems" I have seen built recently are actually mixed-language
> > systems, being a mix of C, C++, and Ada, with the Ada being in the
> > minority (maybe 25%), if one counts all the purchased COTS code in the
> > system.  Typically, the operating system, middleware, and GUI stuff are
> > all in C, and the application code is mostly in Ada (with C bindings, and
> > no Ada runtime).
> 
> No run-time, huh.  That would be interesting to see.

Some of our biggest problems with Ada83 came from the runtime, so the
usual solution was to truncate the runtime, and instead call the
underlying OS (or even CPU hardware) directly from Ada.  This was done
long before C turned up.


> > I would also comment that DoD's recent recinding of the Ada Mandate will
> > likely cause the Ada compiler and tools market to shrink to perhaps as
> > little as one tenth of its prior size, and that significant added
> > investment in Ada compilers and tools is therefore unlikely, at least
> > until the size of the remaining market becomes clear.  
> 
> The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
> -- it will follow the board's recommendation to fund the $15 million for
> infrastructure.

So he's flip-flopped?  I saw his previous missive, a week or two ago, and
it was quite clear.  Actually, he cannot call his words back at this
point; the writing is on the wall.  If you were the product manager for an
ada compiler, wouldn't this stop you in your tracks, afraid to invest more
money, until the smoke cleared?  The very fact that the future of the
mandate is questioned in public and at that level of the DoD is the
story.  If not today, what of tomorrow?  The mandate's days are numbered. 
Will it last long enough for a new investment to be recovered?  A
gut-wrenching question.  Product mamgers get to bet their careers on such
questions.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

Joe said

<<So he's flip-flopped?  I saw his previous missive, a week or two ago, and
it was quite clear.  Actually, he cannot call his words back at this
point; the writing is on the wall.  If you were the product manager for an
ada compiler, wouldn't this stop you in your tracks, afraid to invest more
money, until the smoke cleared?  The very fact that the future of the
mandate is questioned in public and at that level of the DoD is the
story.  If not today, what of tomorrow?  The mandate's days are numbered. 
Will it last long enough for a new investment to be recovered?  A
gut-wrenching question.  Product mamgers get to bet their careers on such
questions.>>

nope, there was no flip-flop here at all. If you perceive one it is because
you have misunderstood what you have read. Sometimes people read into things
that which they wish to perceive, and it is easy to tell what you wish to
perceive!

Re: ada and robots

[Ken Garlington]

Joe Gwinn wrote:
> 
> > > I would also comment that DoD's recent recinding of the Ada Mandate will
> > > likely cause the Ada compiler and tools market to shrink to perhaps as
> > > little as one tenth of its prior size, and that significant added
> > > investment in Ada compilers and tools is therefore unlikely, at least
> > > until the size of the remaining market becomes clear.
> >
> > The Hon. Sec. Paige has said that -- in contrast to rescinding the policy
> > -- it will follow the board's recommendation to fund the $15 million for
> > infrastructure.
> 
> So he's flip-flopped?  I saw his previous missive, a week or two ago, and
> it was quite clear.

These words?

.......................................................................

From: "Paige, Emmett Jr., , OSD/C3I +" <paigee@osd.pentagon.mil>
To: LTC Drew Hamilton <dj7560@eecs1.eecs.usma.edu>
Subject: Re: FW: Reason for Mr. Paige's Decision Unclear
Date: Mon, 10 Mar 1997 18:10:00 -0500

THANK GOD , THIS IS AMERICA.

THE BUCK STOPS HERE .  I HAVE TRIED EVERY ROUTE ONE COULD POSSIBLY HAVE
TO HAVE FOLKS RUN WITH ADA SINCE 1979 WHEN I FIRST GOT INVOLVED. THE
MANDATES HAVE NOT WORKED FOR WEAPON SYSTEMS,C3I SYSTEMS OR OUR BUSINESS
SYSTEMS.  IT HAS ONLY WORKED WHERE I PERSONALLY DECIDED TO FORCE THE
ACTION SUCH AS WITH STANFINS-REDESIGN AND SIDPERS III AS FAR AS MAJOR
SYSTEMS I WAS ASSOCIATED WITH ARE CONCERNED.

I AM VERY SATISFIED AND COMFORTABLE WITH THE ELIMINATION OF THE MANDATE.
WE WILL CONTUNIE TO SUPPORT THE ADA EFFORT TO THE TUNE THAT THE NRC
RECOMMENDED OF APPROX $15MIL PER YEAR. THAT SHOULD BE EVIDENT THAT OUR
INTEREST STILL EXISTS IN ADA.

.......................................................................

> Actually, he cannot call his words back at this
> point; the writing is on the wall.  If you were the product manager for an
> ada compiler, wouldn't this stop you in your tracks, afraid to invest more
> money, until the smoke cleared?  The very fact that the future of the
> mandate is questioned in public and at that level of the DoD is the
> story.

This, of course, implies that DoD contractors choose Ada because it is
mandated. In fact, as Mr. Paige notes above, the mandate may in fact
have
worked _against_ adoption in some areas.

I am currently working on a DoD contract with no language requirement;
we still use Ada. I think if we and other DoD contractors stop using
Ada,
then Ada vendors should be concerned, but so long as there is a viable
customer base, I expect there will be an Ada vendor base to support it.

> If not today, what of tomorrow?  The mandate's days are numbered.
> Will it last long enough for a new investment to be recovered?  A
> gut-wrenching question.  Product mamgers get to bet their careers on such
> questions.

Product managers who cannot survive the removal of Government mandates
have
more problems than choosing languages, now that we are in the age of
acquisition reform. Their "gut-wrenching question" is to decide whether
they should be working at McDonalds or Burger King :)

> 
> Joe Gwinn

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: ada and robots

[Robert Dewar]

<<> > > I would also comment that DoD's recent recinding of the Ada Mandate will
> > > likely cause the Ada compiler and tools market to shrink to perhaps as
> > > little as one tenth of its prior size, and that significant added
> > > investment in Ada compilers and tools is therefore unlikely, at least
> > > until the size of the remaining market becomes clear.>>

I think this was Joe Gwinn's comment (it is consistent with his general
sentiments), but I am not sure.

In any case, we certainly do not see the change in the DoD view of Ada having
any significant negative impact on our business, and on the contrary, we 
regard it as overall positive, since it helps clear the air. Our customers,
both in the US and abroad are Ada enthusiasts for whom the mandate is
in any case irrelevant.

Robert Dewar
Ada Core Technologies

Re: ada and robots

[Joe Gwinn]

In article <33A56EBE.748C@lmco.com>, Ken Garlington
<Kennie.E.Garlington@lmco.com> wrote:

> > So he's flip-flopped?  I saw his previous missive, a week or two ago, and
> > it was quite clear.
> 
> These words [below]?

Yes, and the missive or missives that preceeded it.

> ........................................................................
> 
> From: "Paige, Emmett Jr., , OSD/C3I +" <paigee@osd.pentagon.mil>
> To: LTC Drew Hamilton <dj7560@eecs1.eecs.usma.edu>
> Subject: Re: FW: Reason for Mr. Paige's Decision Unclear
> Date: Mon, 10 Mar 1997 18:10:00 -0500
> 
> THANK GOD , THIS IS AMERICA.
> 
> THE BUCK STOPS HERE .  I HAVE TRIED EVERY ROUTE ONE COULD POSSIBLY HAVE
> TO HAVE FOLKS RUN WITH ADA SINCE 1979 WHEN I FIRST GOT INVOLVED. THE
> MANDATES HAVE NOT WORKED FOR WEAPON SYSTEMS,C3I SYSTEMS OR OUR BUSINESS
> SYSTEMS.  IT HAS ONLY WORKED WHERE I PERSONALLY DECIDED TO FORCE THE
> ACTION SUCH AS WITH STANFINS-REDESIGN AND SIDPERS III AS FAR AS MAJOR
> SYSTEMS I WAS ASSOCIATED WITH ARE CONCERNED.

Now it can be told.

 
> I AM VERY SATISFIED AND COMFORTABLE WITH THE ELIMINATION OF THE MANDATE.
> WE WILL CONTUNIE TO SUPPORT THE ADA EFFORT TO THE TUNE THAT THE NRC
> RECOMMENDED OF APPROX $15MIL PER YEAR. THAT SHOULD BE EVIDENT THAT OUR
> INTEREST STILL EXISTS IN ADA.

As it should be.


> > Actually, he cannot call his words back at this
> > point; the writing is on the wall.  If you were the product manager for an
> > ada compiler, wouldn't this stop you in your tracks, afraid to invest more
> > money, until the smoke cleared?  The very fact that the future of the
> > mandate is questioned in public and at that level of the DoD is the
> > story.
> 
> This, of course, implies that DoD contractors choose Ada because it is
> mandated. In fact, as Mr. Paige notes above, the mandate may in fact
> have worked _against_ adoption in some areas.

I believe that his suspicion is likely correct.  I certainly saw that in
action.  

The limitations of early Ada compilers certainly didn't help, either.  Nor
did the approach of some in the Ada community, insisting that the problems
were really features.


> I am currently working on a DoD contract with no language requirement;
> we still use Ada. I think if we and other DoD contractors stop using
> Ada,
> then Ada vendors should be concerned, but so long as there is a viable
> customer base, I expect there will be an Ada vendor base to support it.

This is as it should have always been: no force-fits.  

The attractions of COTS software will nonetheless draw many DoD entities
to C/C++.  

In the aftermath of the AAS debacle, the FAA has turned against Ada, and
now gives us the choice of C or C++.


> > If not today, what of tomorrow?  The mandate's days are numbered.
> > Will it last long enough for a new investment to be recovered?  A
> > gut-wrenching question.  Product mamgers get to bet their careers on such
> > questions.
> 
> Product managers who cannot survive the removal of Government mandates
> have
> more problems than choosing languages, now that we are in the age of
> acquisition reform. Their "gut-wrenching question" is to decide whether
> they should be working at McDonalds or Burger King :)

Umm.  The survival question hinges upon their ability to make money on
added money invested in Ada tools of any and all kinds.  If their little
profit and loss center doesn't show a good return on investment, they will
soon be flipping burgers, which may cause them to have difficulty meeting
their mortgage.  Thus, they tend to be nervous sorts, skittish in
uncertain environments.  Removal of the mandate makes the environment much
less certain than before, so they tend to hold back.  It's that simple,
and has nothing to do with the merits of Ada.


Joe Gwinn

Re: ada and robots

[Mike Stark]

Joe Gwinn wrote:
<snip> 

> The attractions of COTS software will nonetheless draw many DoD entities
> to C/C++.

Which makes sense for the MIS applications -- I would be wary of
embedding COTS
inside a weapons system though.
> 
> In the aftermath of the AAS debacle, the FAA has turned against Ada, and
> now gives us the choice of C or C++.
> 
God save us all!  The AAS debacle was due to a lot of factors, IMO
primarily
requirements instability and failure to do any useful risk management. 
The 
FAA would do far better to procure and adapt ATC systems already in use
in
Europe or Canada (and readers of Dr. Feldman's periodic postings on
non-DoD
usage know what language _those_ are implemented in ;) than to start
over from
scratch in C or C++.  As a taxpayer, I am apalled by the waste of money
in
starting over.  As an airline passenger, I don't want the controller in
the
tower at Dulles to have his system crash while _my_ flight is in the
landing
pattern.  Just about every common OO language, and especially Ada and
Eiffel,
are more appropriate for safety critical systems!

-- 
--------------------------------------------------------------------------------
Michael Stark                                                  
NASA/GSFC                                           
Phone: (301) 286-5048                                   Code 551
Fax:    (301) 286-0245                                   Greenbelt, MD
20771
 e-mail: michael.e.stark@gsfc.nasa.gov
"I don't give them hell.  I tell the truth and they THINK it's hell!" 
Harry S. Truman
--------------------------------------------------------------------------------

Re: ada and robots

[Joe Gwinn]

In article <33B51B61.2E26@gsfc.nasa.gov>, Mike Stark
<michael.e.stark@gsfc.nasa.gov> wrote:

> Joe Gwinn wrote:
> <snip> 
> 
> > The attractions of COTS software will nonetheless draw many DoD entities
> > to C/C++.
> 
> Which makes sense for the MIS applications -- I would be wary of
> embedding COTS inside a weapons system though.

Well, don't look now, because that's exactly what's happened.  And, by the
way, C is far ahead of Ada in the Air Traffic field, with or without the
FAA.


> > In the aftermath of the AAS debacle, the FAA has turned against Ada, and
> > now gives us the choice of C or C++.
> > 
> God save us all!  The AAS debacle was due to a lot of factors, IMO
> primarily
> requirements instability and failure to do any useful risk management. 
> The 
> FAA would do far better to procure and adapt ATC systems already in use
> in
> Europe or Canada (and readers of Dr. Feldman's periodic postings on
> non-DoD
> usage know what language _those_ are implemented in ;) than to start
> over from
> scratch in C or C++.  As a taxpayer, I am apalled by the waste of money
> in
> starting over.  As an airline passenger, I don't want the controller in
> the
> tower at Dulles to have his system crash while _my_ flight is in the
> landing
> pattern.  Just about every common OO language, and especially Ada and
> Eiffel,
> are more appropriate for safety critical systems!

I generally agree.  I didn't claim that Ada was the reason that AAS
crashed.  I doubt that any language, however perfect, could have saved
AAS.  It's a long and ugly story.   But, fair or not, the FAA has in fact
turned away from Ada.


Joe Gwinn

Re: ada and robots

[John G. Volan]

Joe Gwinn wrote:

> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.  

Could you please elaborate a bit on the technical merits of this claim? 
Your assertion is a curious one, because in my experience Ada83 was very
useful for just this sort of application, when applied with a bit of
care and good judgment.  Before anyone on this group can evaluate the
validity of your claim, we have to discount the possibility that your
bad experiences might have been due to (1) the admittedly poor quality
some early Ada83 implementations (happily now _ancient_ history); (2)
poor understanding of the facilities of Ada83, and how best to apply
them; (3) willful _misunderstanding_ of the facilities of Ada83,
attempting to apply them as if programming in a different language,
thereby losing all the advantages of Ada and creating an artificial set
of "disadvantages"; (4) forced introduction of Ada83 into a culture
openly hostile to its adoption, making its failure in that culture a
foregone conclusion; or (5) all of the above.

> Ada95 is claimed to be better, but I don't have any
> direct experience with it.  

Hmm ... so what you're saying is you don't really have any useful recent
information for us, either way?  

>Actually, not many people do just yet.

Oh, there are a few.  I've done my share of low-level bit-twiddling with
Ada95, and before that, with Ada83. I've been getting away from the
low-level stuff lately, but I know of some other folks with some real
heavy-metal experience with Ada95.  Jim H., care to chime in here? :-)

However, in my experience, it's always been the _abstractions_ that have
saved my butt: Because of the (admittedly cultural) tendency in Ada to
encapsulate lower-level stuff into higher-level abstractions, when push
came to shove on efficiency you could go down into the abstractions,
pick a different implementation, and magically improve performance
across the board, without having to do a lot of massive ripping and
tearing in the application design.  But that takes a certain kind of
engineering skill sadly lacking in the typical silicon jockey weened on
C...

> I
> suspect that most people are using C (perhaps called from Ada) for direct
> control of I/O hardware and the like.

Most likely for cultural, rather than technical reasons.

> Most "Ada systems" I have seen built recently are actually mixed-language
> systems, being a mix of C, C++, and Ada, with the Ada being in the
> minority (maybe 25%), if one counts all the purchased COTS code in the
> system.  Typically, the operating system, middleware, and GUI stuff are
> all in C, and the application code is mostly in Ada (with C bindings, and
> no Ada runtime).

It's really a question of attitude: Is your glass 3/4 empty, or 1/4
full?

To me, given the sheer cultural and marketing inertia propping up C, a
25% inroad of Ada on a project sounds like a phenomenal success against
enormous odds. It demonstrates what many have been saying: Ada is great
for gluing together multi-language code, and for adding a much-needed
layer of abstraction over the miserable bit-twiddling that passes for
APIs these days. It also shows that Ada is a good choice for the code
that you actually have to write and maintain yourself (as opposed to the
code you simply buy from somewhere else).

> Not all Ada compilers offer adequate support for such mixed-language
> systems, especially when it comes time to debug on target (vice host)
> systems.  This can be a severe problem, because it's generally impossible
> to build a competitive offering without extensive use of COTS components,
> which are almost always in C/C++, and impossible to get working soon
> enough to matter without good debugging support.  

If the COTS products you bought are so poorly engineered and documented
that you need to diddle them with a debugger (of all things) to get them
to work, or even just to figure out how to actually interface with them,
then you've got some very serious problems that have nothing to do with
the quality of your Ada compiler. The fact that such products are
written in C or C++ is not exactly a glowing endorsement of either of
those two languages.

> Whatever set of
> compilers and tools you plan to use should be demonstrated to do *exactly*
> what you need done, with sufficient performance, before purchase.  Don't
> assume that anything works until proven.  (A year ago, we very nearly
> bought an Ada that couldn't even link a mixed-language (C and Ada83)
> VxWorks system, let alone execute the code and debug.  Insisting on a true
> and accurate demo saved our butts.)

That was, of course, wise.  But I wonder if the same stringent criteria
have ever been applied to those wonderful COTS products about which I've
heard so much glowing hype^H^H^H^H praise lately... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Joe Gwinn]

In article <33961528.2A9A@sprintmail.com>, johnvolan@sprintmail.com wrote:

> Joe Gwinn wrote:
> 
> > Experience with Ada83 shows that it is very bad at direct control of
> > hardware, especially I/O hardware, and simply does not handle shared
> > memory correctly.  
> 
> Could you please elaborate a bit on the technical merits of this claim? 
> Your assertion is a curious one, because in my experience Ada83 was very
> useful for just this sort of application, when applied with a bit of
> care and good judgment.  Before anyone on this group can evaluate the
> validity of your claim, we have to discount the possibility that your
> bad experiences might have been due to (1) the admittedly poor quality
> some early Ada83 implementations (happily now _ancient_ history); (2)
> poor understanding of the facilities of Ada83, and how best to apply
> them; (3) willful _misunderstanding_ of the facilities of Ada83,
> attempting to apply them as if programming in a different language,
> thereby losing all the advantages of Ada and creating an artificial set
> of "disadvantages"; (4) forced introduction of Ada83 into a culture
> openly hostile to its adoption, making its failure in that culture a
> foregone conclusion; or (5) all of the above.

OK.  Even if you choose to discount my experience as the blatherings of an
idiot.  But remember, I don't have to convince you of anything.  I do have
to deliver a working, reliable product.

Typically, there are only a few code development systems adequate to the
scale of our developments, and toolset quality is a major productivity and
therefore cost and schedule issue.  This is true of all languages, and Ada
is no exception.  Ada toolsets have always been a problem, due largely to
the small size of the Ada market relative to the C/C++ market. 
Engineering energy follows the money, and money follows market share.  It
doesn't matter at all if one language is better than another, the market
governs, right or wrong.

As for Ada83 experience, I have (or know of) both old and new experience,
and most Ada83 compilers were very difficult to use for direct hardware
control.  I suppose one could have made them work, but why would you?  If
it's that hard, it won't be reliable.  We often reverted to assembly code
for the machine control bits, long before C was a true option.  (We did
the same when the base language was Fortran or Pascal, for the same
reasons.)  

The shining exception to Ada83-can't-do-hardware was the late lamented SD
Ada, and some people had success with pre-Rational Verdix.  I think it
depended on which target system was chosen.  

As for Ada83 and shared memory, the problem was that the Ada83 compilers
all believed that only they changed memory, so it was OK to cache data
items in CPU registers for long periods of time.  For the most part, there
was no reliable (and portable) way to tell the compiler different, so we
performed various dances to ensure that Ada83 never knew the whole truth.

In the current development, the one with 25% Ada and the rest C/C++,
mentioned below, which is being coded as we speak, Ada talks only to
VxWorks (via a binding), and only the C-coded I/O drivers touch metal. 
This was decided on architectural grounds, not language issues: the rule
is that application code (regardless of language) is forbidden to touch
metal.  Confining hardware details to these I/O drivers makes the overall
system more portable and resistant to inevitable hardware changes.

I must say that our greatest problem with "willful _misunderstanding_ of
the facilities of Ada83" have been in the direction of incautious overuse
of some inappropriate features of Ada.  Just because a language has a
feature doesn't mean that the feature should be used in a specific
application.  This is true in all languages, and all teams have their
incautious members.

The team is a mixture of Ada lovers (including the chief programmer, who
loves SD Ada), C++ lovers (used for the GUIs), cynical agnostics (such as
myself), and programmers without portfolio.  


> > Ada95 is claimed to be better, but I don't have any
> > direct experience with it.  
> 
> Hmm ... so what you're saying is you don't really have any useful recent
> information for us, either way?  

That is what I said, only more politely.  What's the point you wish to make?  

Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
which the project will be coded against both Ada83 and Ada95 compilers. 
For portability and from fear of the immature, we are staying in the Ada83
subset of Ada95.  


> >Actually, not many people do just yet.
> 
> Oh, there are a few.  I've done my share of low-level bit-twiddling with
> Ada95, and before that, with Ada83. I've been getting away from the
> low-level stuff lately, but I know of some other folks with some real
> heavy-metal experience with Ada95.  Jim H., care to chime in here? :-)

Just as I said: "not many" is the same as "a few".  As I said above, we
are in the process of trying an Ada95 compiler.  However, we will not test
the ability of Ada95 to do direct machine control, although one would hope
and pray that it is improved over Ada83.



> However, in my experience, it's always been the _abstractions_ that have
> saved my butt: Because of the (admittedly cultural) tendency in Ada to
> encapsulate lower-level stuff into higher-level abstractions, when push
> came to shove on efficiency you could go down into the abstractions,
> pick a different implementation, and magically improve performance
> across the board, without having to do a lot of massive ripping and
> tearing in the application design.  But that takes a certain kind of
> engineering skill sadly lacking in the typical silicon jockey weened on
> C...

Abstractions are language independent.  So is programmer skill.

 
> > I
> > suspect that most people are using C (perhaps called from Ada) for direct
> > control of I/O hardware and the like.
> 
> Most likely for cultural, rather than technical reasons.

No.  It's lazyness: cost and schedule.  Current COTS operating systems are
in C, as are I/O drivers for those operating systems.  We can get the code
and reuse it.  Using Ada to write an I/O driver for a C-coded operating
system doesn't seem like the shortest road home to me, especially if a
driver is already available.  Driver writing is difficult, and best
avoided.

 
> > Most "Ada systems" I have seen built recently are actually mixed-language
> > systems, being a mix of C, C++, and Ada, with the Ada being in the
> > minority (maybe 25%), if one counts all the purchased COTS code in the
> > system.  Typically, the operating system, middleware, and GUI stuff are
> > all in C, and the application code is mostly in Ada (with C bindings, and
> > no Ada runtime).
> 
> It's really a question of attitude: Is your glass 3/4 empty, or 1/4
> full?
> 
> To me, given the sheer cultural and marketing inertia propping up C, a
> 25% inroad of Ada on a project sounds like a phenomenal success against
> enormous odds. It demonstrates what many have been saying: Ada is great
> for gluing together multi-language code, and for adding a much-needed
> layer of abstraction over the miserable bit-twiddling that passes for
> APIs these days. It also shows that Ada is a good choice for the code
> that you actually have to write and maintain yourself (as opposed to the
> code you simply buy from somewhere else).

Use of Ada was mandated by our DoD customer.  Actually, they now regret
it, but it's too late to change.  And, Ada isn't gluing anything together,
it's being glued together with C.  None of the APIs know from bits, except
as the unit of data length.


> > Not all Ada compilers offer adequate support for such mixed-language
> > systems, especially when it comes time to debug on target (vice host)
> > systems.  This can be a severe problem, because it's generally impossible
> > to build a competitive offering without extensive use of COTS components,
> > which are almost always in C/C++, and impossible to get working soon
> > enough to matter without good debugging support.  
> 
> If the COTS products you bought are so poorly engineered and documented
> that you need to diddle them with a debugger (of all things) to get them
> to work, or even just to figure out how to actually interface with them,
> then you've got some very serious problems that have nothing to do with
> the quality of your Ada compiler. The fact that such products are
> written in C or C++ is not exactly a glowing endorsement of either of
> those two languages.

This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
products aren't perfect.  Nothing is.  The language in which they are
written is irrelevant to their degree of perfection; it's a matter of how
much energy has or has not been spent on making the code work right.  If
we could find a perfect product, we would buy it.  And, yes, we do have to
debug the system before delivery.  So, debugging is critical to our
ability to deliver on time, etc. 


> > Whatever set of
> > compilers and tools you plan to use should be demonstrated to do *exactly*
> > what you need done, with sufficient performance, before purchase.  Don't
> > assume that anything works until proven.  (A year ago, we very nearly
> > bought an Ada that couldn't even link a mixed-language (C and Ada83)
> > VxWorks system, let alone execute the code and debug.  Insisting on a true
> > and accurate demo saved our butts.)
> 
> That was, of course, wise.  But I wonder if the same stringent criteria
> have ever been applied to those wonderful COTS products about which I've
> heard so much glowing hype^H^H^H^H praise lately... :-)

We always claim we will.  Sometimes we do.  It depends on the
personalities and scars of the team leaders.   It took 6 to 9 months of
broken-record harping and deflection of off-the-point demonstrations
before the abject failure of that toolset became undeniable, even to those
in full denial.  The will to believe, and to just go along, is very
powerful.

Joe Gwinn

Re: ada and robots

[Robert Dewar]

<<Joe said
                                                                                
<<As for Ada83 and shared memory, the problem was that the Ada83 compilers      
all believed that only they changed memory, so it was OK to cache data          
items in CPU registers for long periods of time.  For the most part, there      
was no reliable (and portable) way to tell the compiler different, so we        
performed various dances to ensure that Ada83 never knew the whole truth.>>     
                                                                                
                                                                                
Well for items that could be kept in registers, e.g. small scalars, which       
typically corresponds to the need for messing with IO mapped memory, I fail    
to see why the standard feature - pragma Shared - would not be exactly
what you needed. Please explain why pragma Shared did not do the job. if
you were using a compiler that did not implement pragma Shared, then it
was not an Ada 83 compiler, but a compiler for a subset of the language.

<<abstractions are language independent>>

That is nonsense. Languages have HUGE differences in abstraction capabilities.
Anyone who thinks COBOL has the same abtraction capabilities as say, Pascal,
knows NOTHING about either language.

Re: ada and robots

[Joe Gwinn]

In article <dewar.866303747@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> <<Joe said
>                                                                                

> <<As for Ada83 and shared memory, the problem was that the Ada83
compilers      
> all believed that only they changed memory, so it was OK to cache
data          
> items in CPU registers for long periods of time.  For the most part,
there      
> was no reliable (and portable) way to tell the compiler different, so
we        
> performed various dances to ensure that Ada83 never knew the whole
truth.>>     
>                                                                                

>                                                                                

> Well for items that could be kept in registers, e.g. small scalars,
which       
> typically corresponds to the need for messing with IO mapped memory, I
fail    
> to see why the standard feature - pragma Shared - would not be exactly
> what you needed. Please explain why pragma Shared did not do the job. if
> you were using a compiler that did not implement pragma Shared, then it
> was not an Ada 83 compiler, but a compiler for a subset of the language.

The problem was that not all Ada83 compilers implemented pragma shared
correctly, or the same, so we couldn't depend on pragma shared.  It was
simpler, and --oddly-- more portable to just use assembly.  Ada95 is
supposed to have fixed this problem, which was shared by pragma volatile.


> <<abstractions are language independent>>
> 
> That is nonsense. Languages have HUGE differences in abstraction capabilities.
> Anyone who thinks COBOL has the same abtraction capabilities as say, Pascal,
> knows NOTHING about either language.

Ahh ... let's talk only about modern, mainstream languages, like Ada and
C.  Or, we need also to pull in every cat and dog research language that
ever was, and I grant you that many of them are cripples.  Anyway, it
seems to matter more *who* is doing the abstracting than the details of
the language they use.

Joe Gwinn

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Joe Gwinn wrote:
> 
> 
> Ahh ... let's talk only about modern, mainstream languages, like Ada and
> C.  
> 
> Joe Gwinn

*C* is modern? Dis I miss the <sarcasm> </sarcasm> tags around it?

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[John G. Volan]

Joe Gwinn wrote:

> OK.  Even if you choose to discount my experience as the blatherings of an
> idiot.  

Not at all. An idiot could not have pushed my hot buttons, because his
blatherings would carry no weight. When an intelligent and thoughtful
engineer voices criticisms that are based on outdated information and/or
possible misunderstanding of the technology, that's when my hot buttons
get pushed.

Well, that's no excuse for be to go off the handle. It was hypocritical
of me to complain about personal attacks, and then engage in one, all on
the same day. For that I do apologize. However, with all due respect, I
believe your statements do a disservice to both the past situation with
Ada83, and the current situation with Ada95.

> But remember, I don't have to convince you of anything.  I do have
> to deliver a working, reliable product.

Fair enough.

> Typically, there are only a few code development systems adequate to the
> scale of our developments, and toolset quality is a major productivity and
> therefore cost and schedule issue.  This is true of all languages, and Ada
> is no exception.  Ada toolsets have always been a problem, due largely to
> the small size of the Ada market relative to the C/C++ market.
> Engineering energy follows the money, and money follows market share.  It
> doesn't matter at all if one language is better than another, the market
> governs, right or wrong.

This situation was lamentable for Ada83, but it is rapidly improving for
Ada95.

> As for Ada83 experience, I have (or know of) both old and new experience,

If you have _new_ experience with Ada83, that's a problem you need to
solve as soon as you can. The Ada95 compilers out there (especially
GNAT) are a vast improvement over those that were available for Ada83.
And Ada95 is the standard now; Ada _is_ Ada95.

> and most Ada83 compilers were very difficult to use for direct hardware
> control. I suppose one could have made them work, but why would you?  If
> it's that hard, it won't be reliable. 

I think you're overplaying the difficulties, even those that might have
existed in the past.  They might actually have been trivial to solve
even in Ada83, but they would have seemed insurmountable to anyone not
really motivated to find the Ada83 solution. In any event, early
experiences with Ada95 have indicated that it can do the job, so there
seems little point in bemoaning deficiencies (real or perceived) in
Ada83. 

> We often reverted to assembly code
> for the machine control bits, long before C was a true option.  (We did
> the same when the base language was Fortran or Pascal, for the same
> reasons.)

Always an option, but then such bits should be isolated as quickly as
possible and encapsulated into abstractions which can then be used by
the application logic (which would still represent the bulk of the
program). This is not an argument against writing a hardware control
application in Ada, it only argues that there may be isolated
specialized control functions that can only be done via assembly (in
which case, machine-code insertions would seem ideal). But it is not
clear whether even that much was really necessary in Ada83, and of
course it says nothing about Ada95...

> The shining exception to Ada83-can't-do-hardware was the late lamented SD
> Ada, and some people had success with pre-Rational Verdix.  I think it
> depended on which target system was chosen.

What bothers me about this is that, although you had some negative
experiences with some poor implementations of Ada83, you've also had
some positive experiences with some better implementations of Ada83.
This would argue that the problems you encountered were due to the
quality of particular implementations, not the suitability of the
language itself. Yet, despite this, your predisposition seems to be to
make blanket negative statements about the language. This is why I
suspect a purely cultural prejudice is at work here.

> As for Ada83 and shared memory, the problem was that the Ada83 compilers
> all believed that only they changed memory, so it was OK to cache data
> items in CPU registers for long periods of time.  For the most part, there
> was no reliable (and portable) way to tell the compiler different, so we
> performed various dances to ensure that Ada83 never knew the whole truth.

Surely pragma Volatile would have cured this? (Even in Ada83?)

> In the current development, the one with 25% Ada and the rest C/C++,
> mentioned below, which is being coded as we speak, Ada talks only to
> VxWorks (via a binding), and only the C-coded I/O drivers touch metal.
> This was decided on architectural grounds, not language issues: the rule
> is that application code (regardless of language) is forbidden to touch
> metal.  Confining hardware details to these I/O drivers makes the overall
> system more portable and resistant to inevitable hardware changes.

Fine, reuse is always preferable to writing from scratch. But this says
nothing about the suitability of Ada for low-level hardware control
where a base of driver software does not already exist.

> I must say that our greatest problem with "willful _misunderstanding_ of
> the facilities of Ada83" have been in the direction of incautious overuse
> of some inappropriate features of Ada.  Just because a language has a
> feature doesn't mean that the feature should be used in a specific
> application.  This is true in all languages, and all teams have their
> incautious members.

As you start getting some new Ada95 systems in (or just go ahead and
download GNAT and start playing :-) ), be sure to re-evaluate some of
those "inappropriate features" that might have bit you in the past. In
all likelihood, they were just a symptom of the poor quality of some of
the implementations back then. You may be quite surprised how good their
performance is today.

> > > Ada95 is claimed to be better, but I don't have any
> > > direct experience with it.
> >
> > Hmm ... so what you're saying is you don't really have any useful recent
> > information for us, either way?
> 
> That is what I said, only more politely.  What's the point you wish to make?

My point was that your information is out-of-date, yet you used it to
cast a general indictment of Ada83, and by implication Ada95.  When you
say that others have "claimed" Ada95 is better, but you can't
substantiate those claims, the implication is that those cannot be
substantiated. They can.

> Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
> which the project will be coded against both Ada83 and Ada95 compilers.
> For portability and from fear of the immature, we are staying in the Ada83
> subset of Ada95.

Do the benchmarking, but don't be afraid to try the new features. Of
course, it does depend on the compiler, but some of those new features
(e.g., protected types rather than passive tasks) can allow you to
improve your software designs right now.

> > However, in my experience, it's always been the _abstractions_ that have
> > saved my butt... [snip] ... But that takes a certain kind of
> > engineering skill sadly lacking in the typical silicon jockey weened on
> > C...
> 
> Abstractions are language independent.  So is programmer skill.

Not in my experience. For better or worse, each language has an attached
culture that influences the quality of the engineers trained to program
in it. I've found that programmers with Ada experience were generally
better abstractionists than those with C experience.  I would trust an
Ada programmer programming in C much farther than a C programmer trying
to program in Ada.


> This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
> products aren't perfect.  Nothing is.  The language in which they are
> written is irrelevant to their degree of perfection; it's a matter of how
> much energy has or has not been spent on making the code work right.  If
> we could find a perfect product, we would buy it.  And, yes, we do have to
> debug the system before delivery.  So, debugging is critical to our
> ability to deliver on time, etc.

Over-reliance on debugging is a cost-and-schedule black hole. A much
more profitable course is to: (1) demand excellent documentation of the
behavior of third-party COTS components; (2) regardless of the quality
of such documentation, rigorously test and benchmark the COTS components
to establish their actual behavior _before_ attempting to integrate
them; (3) for the application code, use technical peer reviews
("walkthroughs") at all stages of development -- requirements, design,
and coding -- to catch software flaws as early in the pipeline as
possible (the earlier an error is detected, the cheaper it is to fix);
(4) perform black-box unit testing on the host system for everything
except the lowest-level hardware-specific code (and even for the latter,
it is often useful to build a software simulation of the target hardware
and test against that); (4) use debugging-on-target only as a _very_
last resort. 

> We always claim we will.  Sometimes we do.  It depends on the
> personalities and scars of the team leaders.   It took 6 to 9 months of
> broken-record harping and deflection of off-the-point demonstrations
> before the abject failure of that toolset became undeniable, even to those
> in full denial.  The will to believe, and to just go along, is very
> powerful.

Just for the record, are you still talking about an Ada toolset here, or
about some set of COTS products?  If the former, it would be helpful to
this newsgroup if you identified it, so it can be avoided. We'll
understand, however, if you are reluctant to name names.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[RC]

In <3398E102.54CF@sprintmail.com> by "John G. Volan"
<johnvolan@sprintmail.com>
>> Abstractions are language independent.  So is programmer skill.

>Not in my experience. For better or worse, each language has an attached
>culture that influences the quality of the engineers trained to program
>in it. I've found that programmers with Ada experience were generally
>better abstractionists than those with C experience.  I would trust an
>Ada programmer programming in C much farther than a C programmer trying
>to program in Ada.

Seems reasonable.

I have no statistical evidence but presumably, an Ada programmer tends
to be proud of the readability of his software and attempts to write his
C in a similar style.

As hard as a one line C program fan tries, his Ada code must be
inherently more accessible than his prior equivalent C program.  So the
C world stands to gain from the influence of Ada programmers and C
programmers are unlikely to do that much damage to the Ada world.
Anyone who can do it in C it should have no trouble in Ada.


RC1

Re: ada and robots

[Joe Gwinn]

In article <3398E102.54CF@sprintmail.com>, johnvolan@sprintmail.com wrote:

> Joe Gwinn wrote:
> 
> > OK.  Even if you choose to discount my experience as the blatherings of an
> > idiot.  
> 
> Not at all. An idiot could not have pushed my hot buttons, because his
> blatherings would carry no weight. When an intelligent and thoughtful
> engineer voices criticisms that are based on outdated information and/or
> possible misunderstanding of the technology, that's when my hot buttons
> get pushed.

All information is outdated.  It's only a matter of how much so.

 
> Well, that's no excuse for be to go off the handle. It was hypocritical
> of me to complain about personal attacks, and then engage in one, all on
> the same day. For that I do apologize. 

Accepted.


> ...  However, with all due respect, I
> believe your statements do a disservice to both the past situation with
> Ada83, and the current situation with Ada95.

I've been hyped at a few times too many over the years.  I'll believe the
problems are fixed when I see that they are fixed, in my own lab.


> > Typically, there are only a few code development systems adequate to the
> > scale of our developments, and toolset quality is a major productivity and
> > therefore cost and schedule issue.  This is true of all languages, and Ada
> > is no exception.  Ada toolsets have always been a problem, due largely to
> > the small size of the Ada market relative to the C/C++ market.
> > Engineering energy follows the money, and money follows market share.  It
> > doesn't matter at all if one language is better than another, the market
> > governs, right or wrong.
> 
> This situation was lamentable for Ada83, but it is rapidly improving for
> Ada95.

So many people are saying.  We shall see; our experiments are just
beginning.  However, direct control of hardware by Ada is not in our
architecture, as only VxWorks I/O drivers are permitted to touch the
metal, so that issue will not be tested.


> > As for Ada83 experience, I have (or know of) both old and new experience,
> 
> If you have _new_ experience with Ada83, that's a problem you need to
> solve as soon as you can. The Ada95 compilers out there (especially
> GNAT) are a vast improvement over those that were available for Ada83.
> And Ada95 is the standard now; Ada _is_ Ada95.

Our current (as of last week) experience with Ada83 is that the generated
code is *very* slow; this is why we are flirting with Ada95, which appears
to be a factor faster.  C is a bit faster still than Ada95, but not so
much that one would choose one over the other on that alone.  When the
experiments are complete, I may publish actual test results.  


> > and most Ada83 compilers were very difficult to use for direct hardware
> > control. I suppose one could have made them work, but why would you?  If
> > it's that hard, it won't be reliable. 
> 
> I think you're overplaying the difficulties, even those that might have
> existed in the past.  They might actually have been trivial to solve
> even in Ada83, but they would have seemed insurmountable to anyone not
> really motivated to find the Ada83 solution. In any event, early
> experiences with Ada95 have indicated that it can do the job, so there
> seems little point in bemoaning deficiencies (real or perceived) in
> Ada83. 

See above.  By "reliable", I also meant to include "portable".  Even if I
got it to work under one compiler, the next one has its own set of
oddities.  See below.


> > We often reverted to assembly code
> > for the machine control bits, long before C was a true option.  (We did
> > the same when the base language was Fortran or Pascal, for the same
> > reasons.)
> 
> Always an option, but then such bits should be isolated as quickly as
> possible and encapsulated into abstractions which can then be used by
> the application logic (which would still represent the bulk of the
> program). This is not an argument against writing a hardware control
> application in Ada, it only argues that there may be isolated
> specialized control functions that can only be done via assembly (in
> which case, machine-code insertions would seem ideal). But it is not
> clear whether even that much was really necessary in Ada83, and of
> course it says nothing about Ada95...

With the Ada83 compilers of our experience, except for SD Ada, it *was*
necessary, and so it was safer to simply have a few assembly-coded (or
C-coded) machine control subroutines.  

I guess I don't see why people are so hard over on defending Ada here. 
It's not like we are talking about much code, and the only traditional HOL
intended to do anything like this is C, which is why one generally did
this stuff in assembly.  The fact that in my experience Ada doesn't do
hardware control well isn't a reason to use or not use Ada for a project,
and I have no religious objection to use of multiple languages in a
project.

 
> > The shining exception to Ada83-can't-do-hardware was the late lamented SD
> > Ada, and some people had success with pre-Rational Verdix.  I think it
> > depended on which target system was chosen.
> 
> What bothers me about this is that, although you had some negative
> experiences with some poor implementations of Ada83, you've also had
> some positive experiences with some better implementations of Ada83.
> This would argue that the problems you encountered were due to the
> quality of particular implementations, not the suitability of the
> language itself. Yet, despite this, your predisposition seems to be to
> make blanket negative statements about the language. This is why I
> suspect a purely cultural prejudice is at work here.

I guess that all but one then implementation of Ada83 was poor, then.  I
don't know that much has changed, because the Ada compiler vendors have
put their efforts into Ada95, leaving Ada83 on maintenance.  As one would
expect.  And certainly what the newsgroup is saying.


> > As for Ada83 and shared memory, the problem was that the Ada83 compilers
> > all believed that only they changed memory, so it was OK to cache data
> > items in CPU registers for long periods of time.  For the most part, there
> > was no reliable (and portable) way to tell the compiler different, so we
> > performed various dances to ensure that Ada83 never knew the whole truth.
> 
> Surely pragma Volatile would have cured this? (Even in Ada83?)

In theory, it should have.  However, only SD and perhaps DEC got the
meaning of "volatile" completely correct, so we couldn't depend on it, and
so couldn't use it.  Back to assembly.


> > In the current development, the one with 25% Ada and the rest C/C++,
> > mentioned below, which is being coded as we speak, Ada talks only to
> > VxWorks (via a binding), and only the C-coded I/O drivers touch metal.
> > This was decided on architectural grounds, not language issues: the rule
> > is that application code (regardless of language) is forbidden to touch
> > metal.  Confining hardware details to these I/O drivers makes the overall
> > system more portable and resistant to inevitable hardware changes.
> 
> Fine, reuse is always preferable to writing from scratch. But this says
> nothing about the suitability of Ada for low-level hardware control
> where a base of driver software does not already exist.

I didn't claim that it did.  Our project is what it is.


> > I must say that our greatest problem with "willful _misunderstanding_ of
> > the facilities of Ada83" have been in the direction of incautious overuse
> > of some inappropriate features of Ada.  Just because a language has a
> > feature doesn't mean that the feature should be used in a specific
> > application.  This is true in all languages, and all teams have their
> > incautious members.
> 
> As you start getting some new Ada95 systems in (or just go ahead and
> download GNAT and start playing :-) ), be sure to re-evaluate some of
> those "inappropriate features" that might have bit you in the past. In
> all likelihood, they were just a symptom of the poor quality of some of
> the implementations back then. You may be quite surprised how good their
> performance is today.

I'm not sure we have the budget or schedule for much playing, but some
will be done, under the rubric "pathfinding".

 
> > > > Ada95 is claimed to be better, but I don't have any
> > > > direct experience with it.
> > >
> > > Hmm ... so what you're saying is you don't really have any useful recent
> > > information for us, either way?
> > 
> > That is what I said, only more politely.  What's the point you wish to make?
> 
> My point was that your information is out-of-date, yet you used it to
> cast a general indictment of Ada83, and by implication Ada95.  When you
> say that others have "claimed" Ada95 is better, but you can't
> substantiate those claims, the implication is that those cannot be
> substantiated. They can.

I said just what I said, and implied nothing.  I thought I was quite clear
about what was known and what was rumoured.

 
> > Anyway, on Ada95, not yet.  We are just now benchmarking the Ada83 code in
> > which the project will be coded against both Ada83 and Ada95 compilers.
> > For portability and from fear of the immature, we are staying in the Ada83
> > subset of Ada95.
> 
> Do the benchmarking, but don't be afraid to try the new features. Of
> course, it does depend on the compiler, but some of those new features
> (e.g., protected types rather than passive tasks) can allow you to
> improve your software designs right now.

Actually, the benchmarks must stay in the Ada83 subset of Ada95, which is
after all the bulk of Ada95, so that we can directly compare performance,
size, etc.  The benchmarks are reasonably large bits of actual application
code, which wouldn't have any reason to use the new parts of Ada95 anyway.


> > > However, in my experience, it's always been the _abstractions_ that have
> > > saved my butt... [snip] ... But that takes a certain kind of
> > > engineering skill sadly lacking in the typical silicon jockey weened on
> > > C...
> > 
> > Abstractions are language independent.  So is programmer skill.
> 
> Not in my experience. For better or worse, each language has an attached
> culture that influences the quality of the engineers trained to program
> in it. I've found that programmers with Ada experience were generally
> better abstractionists than those with C experience.  I would trust an
> Ada programmer programming in C much farther than a C programmer trying
> to program in Ada.

In my experience, the best programmers were able to rise above the here
and now of whichever language and operating system they were then using. 
I don't know that I believe that any language, however good, can make good
programmers from bad programmers.  It's only a language.


> > This is embedded realtime.  Built for speed, not comfort.  Yes, COTS
> > products aren't perfect.  Nothing is.  The language in which they are
> > written is irrelevant to their degree of perfection; it's a matter of how
> > much energy has or has not been spent on making the code work right.  If
> > we could find a perfect product, we would buy it.  And, yes, we do have to
> > debug the system before delivery.  So, debugging is critical to our
> > ability to deliver on time, etc.
> 
> Over-reliance on debugging is a cost-and-schedule black hole. A much
> more profitable course is to: (1) demand excellent documentation of the
> behavior of third-party COTS components; (2) regardless of the quality
> of such documentation, rigorously test and benchmark the COTS components
> to establish their actual behavior _before_ attempting to integrate
> them; (3) for the application code, use technical peer reviews
> ("walkthroughs") at all stages of development -- requirements, design,
> and coding -- to catch software flaws as early in the pipeline as
> possible (the earlier an error is detected, the cheaper it is to fix);
> (4) perform black-box unit testing on the host system for everything
> except the lowest-level hardware-specific code (and even for the latter,
> it is often useful to build a software simulation of the target hardware
> and test against that); (4) use debugging-on-target only as a _very_
> last resort. 

Well, it's a nice theory.  Would that it were true in practice.  Somehow,
we always seem to end up in the lab at 3:00 AM.  If we were only smarter.


> > We always claim we will.  Sometimes we do.  It depends on the
> > personalities and scars of the team leaders.   It took 6 to 9 months of
> > broken-record harping and deflection of off-the-point demonstrations
> > before the abject failure of that toolset became undeniable, even to those
> > in full denial.  The will to believe, and to just go along, is very
> > powerful.
> 
> Just for the record, are you still talking about an Ada toolset here, or
> about some set of COTS products?  If the former, it would be helpful to
> this newsgroup if you identified it, so it can be avoided. We'll
> understand, however, if you are reluctant to name names.

Both; they are one in the same.  You have heard of them, too.

I don't know that I could afford the libel suit, even if I won it.  


Joe Gwinn

Re: ada and robots

[Jon S Anthony]

> memory correctly.  Ada95 is claimed to be better, but I don't have
> any direct experience with it.

Significantly better.  Quite different.


> Actually, not many people do just yet.

Au contrair - many are using it.

Get it _free_ if you like (binaries for most everything) at

ftp://cs.nyu.edu/pub/gnat/

> I suspect that most people are using C (perhaps called from Ada) for
> direct control of I/O hardware and the like.

Well, that's also quite possible as Ada95 provides out of the box
standard built in connection to C (and Fortran).

> Not all Ada compilers offer adequate support for such mixed-language

All Ada95 compilers do.

> VxWorks system, let alone execute the code and debug.  Insisting on a true
> and accurate demo saved our butts.)

Sound enough advice.  You can check this for yourself with Ada95 via
the free (industrial strength, I might add) compilers mentioned above.


> likely cause the Ada compiler and tools market to shrink to perhaps as
> little as one tenth of its prior size, and that significant added
> investment in Ada compilers and tools is therefore unlikely, at least

Nothing like good ol' FUD.  These 1/10's and 1/100's are just pulled
from where the sun doesn't shine.  Where are the studies?  Quote them
please.


> until the size of the remaining market becomes clear.  A significant
> shrink is widely expected

By who (or is that "whom"?)?  In any event, the opposite has seemed to
have been happening.  This is largely the result of free and cheap
compilers with full typical Windoze IDEs - check Aonix for example:
http://www.thomsoft.com/Products/Ada/ada.html

Also, only in the land of software would anyone actually suggest that
one should not use a better tool, technique, process, whatever to
build your product, because most of your _competition_ is using the
inferior tool, technique, process, whatever.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Joe Gwinn]

In article <JSA.97Jun4200305@alexandria.organon.com>,
jsa@alexandria.organon.com (Jon S Anthony) wrote:

> > Not all Ada compilers offer adequate support for such mixed-language
> 
> All Ada95 compilers do.

That has not been our experience, especially when debugging of tasks
containing procedures in different languages.  The common (and inadequate)
solution is two independent and isolated debugging systems, one per
language, with no way to follow the thread of execution whereever it may
go.  We can use such a system, but why would we?  Getting systems to work
is hard enough as it is.


> > likely cause the Ada compiler and tools market to shrink to perhaps as
> > little as one tenth of its prior size, and that significant added
> > investment in Ada compilers and tools is therefore unlikely, at least
> 
> Nothing like good ol' FUD.  These 1/10's and 1/100's are just pulled
> from where the sun doesn't shine.  Where are the studies?  Quote them
> please.

Been reading them for years.  Some came from the Ada Joint Program
Office.  Don't have the references right at hand.  Do you have any studies
that say that Ada exceeds C?  I hope not.  They cannot be right.  The
difference isn't 10%, it's at least 10:1.  If if were the case that the
markets of C and Ada were in rough parity, we wouldn't get laughed at when
we ask various COTS vendors if they have an Ada interface to their
product.

Go into any technical bookstore and measure the relative shelf space
devoted to the various languages.  That's as good a metric as any, and
easy.  The stores know what does and does not sell, and the stores don't
care what the books are about, so long as people buy them.


> > until the size of the remaining market becomes clear.  A significant
> > shrink is widely expected
> 
> By who (or is that "whom"?)?  In any event, the opposite has seemed to
> have been happening.  This is largely the result of free and cheap
> compilers with full typical Windoze IDEs - check Aonix for example:
> http://www.thomsoft.com/Products/Ada/ada.html

People I have talked to.  Haven't seen anything published just yet, but
the mandate issue just came up.  I don't really believe that the market
share of Ada has been growing realtive to C/C++.  Do you?  


> Also, only in the land of software would anyone actually suggest that
> one should not use a better tool, technique, process, whatever to
> build your product, because most of your _competition_ is using the
> inferior tool, technique, process, whatever.

Ah, it depends on your definition of "better".  The basic issue in how
good the tools are for a language is simply the size of that language's
market.  The technical details of the language are basically irrelevant,
and the best language doesn't necessarily win.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

Joe said

<<That has not been our experience, especially when debugging of tasks
containing procedures in different languages.  The common (and inadequate)
solution is two independent and isolated debugging systems, one per
language, with no way to follow the thread of execution whereever it may
go.  We can use such a system, but why would we?  Getting systems to work
is hard enough as it is.>>

Note that you were responding *specifically* to a point about Ada 95. Since
you are certainly not as far as I know a customer of ACT, you must be using
other Ada 95 compilers (and more than one) to make such a judgment about
the common solution (which certainly is not true of GNAT, and not true
of at least some other Ada 95 compilers with which I am familiar).

Can you please be more specific, or are you speaking from general (incorrect)
hearsay without any real experience -- I guess the latter. 

As for the tools market, what makes you think the Ada and C tools markets
are disjoint. Many tools that work for C work just fine for Ada (in an open
systems context such as the approach GNAT uses, it would be surprising if it
were otherwise). For example, it is perfectly possible to use a CM tool like
Clearcase with GNAT. Yes, it is nice if a little bit of tailoring of these
tools can be done. For example, Purify works pretty well with GNAT, and a
fair number of our customers have used it successfully. However, it would
work better if a little bit of specialization work were done. The Ada market
may not be able to support the investmeent necessary for duplicating the
production of tools like this, but it can and will support the investment
for their specialization where this is worth while.

Another example, GDB is a pretty competent multi-target multi-language
debugger. Even in its completely Ada-unknowledgable form, it is usable
with Ada 95 (usable enough that most of the developers on the GNAT project
have never used anything else -- this is largely because of its very
effective ability to call user level functions, so that debugging functions
can be placed in the image). GDB is a large and complicated program, with a
lot of complex target dependent stuff (e.g. it needs to know about stack
formats). We certainly do not have the resources to duplicate this work.
But we *do* have the resources to specialize GDB so that it knows more
about Ada. The current Ada mode is a first step in that direction, but a
lot more is coming in this direction.

Similarly, a lot of work has been done on visual interfaces for GDB (there
are several, including DDD, GDBTK, PMGDB, and a new one that we are creating
from scratch). We could not afford to duplicate this entire collection, but
it is highly desirable to have a choice, since personal tastes vary a lot
in this area. We can afford to do a little Ada specialization (and it is
interesting to note for example that the folks taking care of DDD, though
certainly not Ada mainstream people, have on their own steam made some
nice modifications to DDD to better accomodate Ada).

Yes, Ada is a much smaller market than C++, so it is not worth while for
tool makers to spend huge amounts of effort rebuilding their tools from
scratch for Ada. It is however by no means a zero size market, so a number
of tool makers are quite interested in capturing this incremental market
if it means doing relatively small amounts of incremental work on their
existing tools.

This is what makes it practical for Ada 95 to develop and maintain a strong
set of tools, even if and though Ada 95 remains a small market compared to
C++ or Java or whatever language-du-jour is.

Robert Dewar
Ada Core Technologies.

Re: ada and robots

[Robert Dewar]

Joe said

<<In practice, C was much more successful than Ada83 at riding metal. 
Experience with Ada83 shows that it is very bad at direct control of
hardware, especially I/O hardware, and simply does not handle shared
memory correctly.>>

Please explain this claim. Please post sample code that you think is
defined in C and handles shared memory correctly ...

Re: ada and robots

[Joe Gwinn]

In article <dewar.865941342@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Joe said
> 
> <<In practice, C was much more successful than Ada83 at riding metal. 
> Experience with Ada83 shows that it is very bad at direct control of
> hardware, especially I/O hardware, and simply does not handle shared
> memory correctly.>>
> 
> Please explain this claim. Please post sample code that you think is
> defined in C and handles shared memory correctly ...

There is tons of such code available for free on the internet.  Just look
for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
Packages are another example.  

Even C-coded I/O drivers and kernel initialization sequences resort to
some assembly code.  

As for shared memory, look into the handling of driver comm pools, queues
shared between tasks and also with ISRs.  And so on.

For UNIX drivers, there are multiple books available on exactly how to
write such drivers, all in C.  Most include (annotated) sample driver
code.  

I would submit that there is ample evidence that C can be used for direct
hardware control, and for shared memory.  

I would not claim that all who have tried such things have succeeded,
regardless of language.  Many programmers couldn't write an I/O driver if
their life depended on it.


Joe Gwinn

Re: ada and robots

[Robert Dewar]

I asked Joe for specific code, and he responded:

<<There is tons of such code available for free on the internet.  Just look
for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
Packages are another example.  
 
Even C-coded I/O drivers and kernel initialization sequences resort to
some assembly code.  
 
As for shared memory, look into the handling of driver comm pools, queues
shared between tasks and also with ISRs.  And so on.
 >>

Sorry that is not what I asked for. I asked for specific code. If you are
just repeating what others have told you, fine, such second hand information
is often ill-informed and inaccurate. But if on the other hand, you have a
real technical point to make, please illustrate it with very specific code.

(P.S. I have written lots of device drivers, and I cannot think of anything
I have ever done that could not be done in Ada), but if you think you have
such an example, let's see it!

Re: ada and robots

[George Haddad]

Robert Dewar wrote:
> (P.S. I have written lots of device drivers, and I cannot think of anything
> I have ever done that could not be done in Ada), but if you think you have
> such an example, let's see it!

   I have the greatest respect for you, Prof. Dewar, and read avidly
most of your posts here in comp.lang.ada.  That having been said, it
would seem that, in the above paragraph, you are giving us only vague
(though undoubtedly well-informed and accurate :-)) assurances of the
sort you would scorn to receive in such a discussion.  Which device
drivers _did_ you write in Ada?  :-)
-- 
*****************************************************************
I found these opinions on my doorstep, would you please give them a good
home?

Re: ada and robots

[Matthew S. Whiting]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8702 bytes --]


Robert Dewar wrote:
> 
> I asked Joe for specific code, and he responded:
> 
> <<There is tons of such code available for free on the internet.  Just look
> for I/O drivers, such as for UNIX and VxWorks. VxWorks Board Support
> Packages are another example.
> 
> Even C-coded I/O drivers and kernel initialization sequences resort to
> some assembly code.
> 
> As for shared memory, look into the handling of driver comm pools, queues
> shared between tasks and also with ISRs.  And so on.
>  >>
> 
> Sorry that is not what I asked for. I asked for specific code. If you are
> just repeating what others have told you, fine, such second hand information
> is often ill-informed and inaccurate. But if on the other hand, you have a
> real technical point to make, please illustrate it with very specific code.
> 
> (P.S. I have written lots of device drivers, and I cannot think of anything
> I have ever done that could not be done in Ada), but if you think you have
> such an example, let's see it!

Robert,

I'm not Joe, but I've been having a similar line of, shall we say,
"discussion" with a colleague where I work.  Here's his reply when I
asked for specific issues that C or C++ could easily handle that were
difficult or impossible to handle in Ada.  I'm not an Ada expert so I'm
not qualifed to respond to his list point-by-point, and you may not wish
to take the time, but here at least are some specific points rather than
vague generalities.  As background, the author of the note below is
currently quite proficient in C and C++ and formerly programmed in Ada
(Ada83) for a defense industry contractor.  He's taken a cursory look at
Ada95, but remains convinced that Ada is inferior to C++ (and probably
even C) for the kinds of systems we develop (industrial process, machine
and motion control systems primarily).

I've tried to sanitize the message below to eliminate the name of my
company and the author.  Hopefully, I succeeded (Netscape has no "find"
function when doing a newsgroup reply ... sigh).

Matt

>Matt,
>
>OK � I am glad you are not a Macintosh advocate too. I guess this Ada debate
>is too much like debating PC vs. Macintosh (or I guess this is how I associate
>the Ada camp trying to get acceptance). The debate is very similar. Ha ha �
>
>I remember the discussion with [another colleague] and my comments about Ada. I
>remember stating that Ada was by no means a good language of choice for doing
>low-level complex programming, but you could use Ada (as well as many other
>languages that are also non-efficient). I said, "Ada is not as effective or
>efficient as C/C++ in writing device drivers (low-level programming)�", which
>I do not think any programmer could argue due to many factors:
>
>*      Ada's strong typing does not allow very complex structures to be
>manipulated and/or used efficiently due to its typing scheme (which in turn
>causes a programmer to code many more lines of code, or to structure a
>particular data set in a ineffective manner, or not at all). 
>*      Ada does not support discriminant unions (which are extremely useful,
>almost required). In fact, discriminant union support is required within the
>data structures that are used within the [one of our systems] data architecture; >and in fact,
>are very critical for supporting applications that need to support many data
>types within a limited memory area. Ada does have some hacks to get around
>some of these issues (using the USE AT construct) but still can not get
>around certain design issues. For example, if a designer wanted to build a
>data area that would store strings, booleans, ints, longs, float, and doubles
>all under one type called MyType (which was defined as a structure that
>contained a type discriminant, and a union to hold the desired value) and
>then pass an array of these elements (with mixed types) to a routine for
>processing� A Ada programmer might as well forget it�  Also, I believe this
>is an issue when declaring an object array with Ada95 where all elements must
>be of the defined type; yet using the C++ array template, one may store
>objects of different types into the same array.
>*      Ada does not support conforment arrays. You can not pass an array with 5
>elements to a routine one time and then pass an array of 10 elements the next
>because of the typing. This is an extremely critical aspect that is extremely
>difficult to get around within Ada compared with C/C++ or Pascal. Moreover,
>this functionality is almost required when processing communications packets
>that may be variable-sized.
>*      Ada does not support variable length parameter lists. This is a very tacky
>aspect of the language, which in turn, causes many more lines of code to be
>generated to support some functionality that requires different data inputs.
>This limitation can greatly effect a programs function (overload) count due
>to this limitation. For example, lets look at the following simple
>non-critical I/O code:
>
>C Code: 
>
>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
>nForce- %f\n", roll, torque, velocity, force);
>
>Ada Code:
>
>Ada.Text_IO.New_Line(2);
>Ada.Text_IO.Put("The roller outputs for Roll[");
>Ada.Int_IO.Put(roll);
>Ada.Text_IO.Put("] are:");
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Torque-");
>Ada.Real_IO.Put(torque);
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Velocity-");
>Ada.Real_IO.Put(velocity);
>Ada.Text_IO.New_Line;
>Ada.Text_IO.Put("Force-");
>Ada.Real_IO.Put(force);
>Ada.Text_IO.New_Line;
>
>I don't think a lot of debug text I/O to a VT320 screen included in a system
>for debug would be very nice � And this is a simple example of why variable
>length parameter lists are so very important. Just think if you had a
>Parser() routine that could parse a variable length input list of 20
>parameters �, you sure would have a lot of Ada routines for each list item to
>write and maintain.
>
>*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a superset of CORBA
>IDL and offers many complex data types that are essential for low-level,
>high-performance system applications that are not supported in Ada, Java, �
>This lack or inability of the language to handle complex data structures can
>again increase the lines of coding.
>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
>that under certain OS's we may be required to write the interface bindings to
>vendor routines, and these may not be commercially available. And looking at
>our current IO vendors, they appear to be supplying C/C++ libraries, which
>almost guarantees that we will need C bindings to what OS we're using.
>VxWorks may have bindings, but what about pSOS, and other potential OS's. I
>do not see to many IO vendors supplying Ada routines for the hardware�
>
>
>Here are just a few items that truly make Ada very ineffective and
>inefficient to program in � And many of them focus around the inability of
>the language to support complex (but required) data structures and types, as
>well as, the intolerable type scheme. The fact the Ada has the following
>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
>within the language unless they are required so that the language can perform
>certain tasks (which require them). Once elements such as these are used (and
>they must in many low-level systems programs), the touted type-safe, robust
>Ada system is no longer� but now in the same field as many other languages.
>
>
>There truly are many more serious negatives with Ada programming versus
>C/C++. I, as well as many others, realize that one must design and program a
>system correctly (with proper CM and SQA) but feel that C++ by far gives a
>programmer much more programming efficiencies than Ada; and in the long run a
>better performing and reliable system.
>
>I think I could go on and on about many different areas that would be
>negatives for [our company] (regarding resourcing, software development, vendor
>support, tool & analysis support, �) but I don't want to keep re-living these
>facts. I feel that C++ and C are buy far the best solution for [our company]. We
>are currently using C/C++, many vendors that we have are using C++ (and do
>not support Ada), DSP development has now moved to C, etc., along with the
>items I placed in my decision analysis.
>
>Hopefully I have given you enough reasons why Ada is not any programmers
>choice for low-level systems programming. If not, we should try writing a
>device driver for a simple timer card for NT. I think it would become
>extremely clear at that point.

Re: ada and robots

[Samuel Mize]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5683 bytes --]


Note that I make some comments about the person Mr. Whiting quoted,
but none about Mr. Whiting.  Some quotations reformatted for length.

Stephen Leake wrote:
> 
> Matthew S. Whiting wrote:
>  ( second hand list of supposed Ada deficiencies )
...
> > >*      Ada does not support discriminant unions (which are
...
> This is precisely the Ada discriminant record:

Ah, but you can't hand-code the discriminant values.  This makes it
harder to interface to existing C code, which of course makes C
fundamentally better.

Besides, you can't load the variable with one type and then read it
as another type.  In C it's simple and safe, while in Ada it requires
Unchecked_Conversion, which everyone knows is dangerous.


> > >Also, I believe this
> > >is an issue when declaring an object array with Ada95 where all
> > >elements must be of the defined type; yet using the C++ array
> > >template, one may store objects of different types into the same
> > >array.

Is this template something that couldn't be done with a generic,
or a tagged type?  Or is the complainer just ignorant?


> > >*      Ada does not support variable length parameter lists. This
> > >is a very tacky aspect of the language, which in turn, causes
> > >many more lines of code to be generated to support some
> > >functionality that requires different data inputs.  This
> > >limitation can greatly effect a programs function (overload)
> > >count due to this limitation.
> 
> This is true. The reason is type safety and run-time simplicity. When
> porting GCC to a new processor, one of my biggest problems was getting
> variable arguments working; I'm still finding bugs related to this!
> But even given a correct implementation, variable argument lists are
> just not type safe. Ada provides alternatives that are safe (see
> MyType above).

At the slightest error, a procedure with a variable-length parameter
list will read undefined values off the end of the stack.  What
happens if you make this call in C:
   printf ("%s%s%d%e");

For safer ways to get variable-length lists of parameters, see the "Ada
Can Do It" writeup at www.adahome.com.


> > >*      Interface Packages - Another extremely dangerous issue with
> > >Ada is the fact that under certain OS's we may be required to
> > >write the interface bindings to vendor routines, and these may
> > >not be commercially available.

Why is this dangerous?  Can't they afford a week's worth of effort to
write a thin partial binding?  Or is he just too stupid to write one?


> A side benefit of writing your own bindings is that you become more
> aware of the details of the system you are binding to; this is
> sometimes a good thing.

Plus you can write the interface layer to provide the abstractions you
need in your programs.  Plus, when you port to another OS, you have
isolated all the system dependencies -- unless you're talking about
system functions that have ISO standard bindings, this is likely to
cost you some effort if you are using vendor-supplied bindings.


> > >USE AT, Unchecked_Conversion, Unchecked_Access, and
> > >Unchecked_Deallocation; one might ask why Ada needs such dangerous
> > >elements within the language unless they are required so that the
> > >language can perform certain tasks (which require them).

Duh.  I don't leave my power tools plugged in and laying around the
workshop, let alone keep them with me wherever I go.

> > >... Once elements such as these are used (and
> > >they must in many low-level systems programs), the touted
> > > type-safe, robust Ada system is no longer� but now in the same
> > >field as many other languages.

In the limited and well-identified areas where unchecked programming
is being done, yes.  In those parts of your code -- typically less
than 5% if you design carefully -- you have to be as paranoid, and do
as much scut-level debugging, as a C programmer.

In the rest of your code, the compiler is helping you avoid fencepost
errors, rogue pointers, accidental misuse of data, and so on.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
But the real core of the complainant's thought process is clear: he
says that Ada isn't a "programmer's language," and often refers to
the (to him) serious problem of writing more code to do something.

What he means is that it isn't a hacking language.

He's right.  It isn't a language for hackers.  It's a language
for software designers -- people who want automated help designing
and building a program that works right EVERY time, reliably, for
a long time, that you can modify and port to new systems.

It IS hard to just sit down and bang out code in Ada.  You have to
pick a coherent design, lay out specs that express that design, and
code to your design.  If you're going to use things in a different
way than you specified -- for instance, view an integer as an array
of bytes -- you have to tell the compiler what you're doing.

Those "extra" lines of code tell the compiler what you're thinking,
and how you mean things to work.  Then the compiler can check you
and spot your mistakes.  Some people don't like this approach.
They say with great vigor that a good programmer should be allowed
to do anything by the compiler, trusting to his skill and care to
get things right.  They are deeply certain that they need no help
managing the complexity of their own code.  They are usually quite
skilled at debugging.

Many Ada programmers have only rudimentary debugging skills, even
after years of building successful programs.  Think about it.

Samuel Mize

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ada and robots

[Steve O'Neill]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]


Samuel Mize wrote:
> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.

It's simple in C but not necessarily safe.  

and Mr. Whiting said
>>>>USE AT, Unchecked_Conversion, Unchecked_Access, and
>>>>Unchecked_Deallocation; one might ask why Ada needs such dangerous
>>>>elements within the language unless they are required so that the
>>>>language can perform certain tasks (which require them).

I am constantly flabbergasted by the argument that Unchecked_Conversion
and its close cousins are dangerous while uncontrolled and un-obvious
use of typecasting and address manipulation in C are acceptable.  Let's
face it folks, when you're playing around at this level it's all
inherently dangerous.  But there are times when this level of control is
necessary.  The point that I like about Ada is that it makes you
recognize that you are in dangerous territory while C hands you the rope
with which to hang yourself.  In my endeavours I try to layer
applications such that the application has some insulation from the
metal.  Ada lets me do this quite well, thank you.

>>>>... Once elements such as these are used (and
>>>>they must in many low-level systems programs), the touted
>>>> type-safe, robust Ada system is no longer� but now in the same
>>>>field as many other languages.

Maybe so, but at least I can more easily identify those areas of
"thin-ice".
 
-- 
Steve O'Neill                    Sr. Software Engineer
Sanders                          Nashua, New Hampshire
(603) 885-9765 (voice)           (603) 885-2483 (fax)

Re: ada and robots

[Anonymous]

<338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net>
<338F9D05.5EB3@bix.com> <5mqpj3$bc5$1@goanna.cs.rmit.edu.au>
<33930245.12A1@sprintmail.com> <5mv984$7kn@news.emi.com>
<gwinn-0306971836410001@smc19.ed.ray.com> <dewar.865941342@merv>
<gwinn-1006971907100001@dh5055139.res.ray.com> <dewar.866044546@merv>
<33A5D644.37A3@epix.net> <33A6D407.53416C1E@link.com>

On Wed, 18 Jun 1997 10:14:06 -0400, Steve O'Neill
<"x0955$"@sanders.lockheed.com> wrote:

> Samuel Mize wrote:
> > Besides, you can't load the variable with one type and then read it
> > as another type.  In C it's simple and safe, while in Ada it requires
> > Unchecked_Conversion, which everyone knows is dangerous.
> 
> It's simple in C but not necessarily safe.  
> 
> and Mr. Whiting said
> >>>>USE AT, Unchecked_Conversion, Unchecked_Access, and
> >>>>Unchecked_Deallocation; one might ask why Ada needs such dangerous
> >>>>elements within the language unless they are required so that the
> >>>>language can perform certain tasks (which require them).
> 
> I am constantly flabbergasted by the argument that Unchecked_Conversion
> and its close cousins are dangerous while uncontrolled and un-obvious
> use of typecasting and address manipulation in C are acceptable.
..

I agree with your point, but I interpreted Mize's comment as sarcasm
agreeing with you too.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: ada and robots

[Kenneth W. Sodemann]

On Tue, 17 Jun 1997 13:14:31 -0500, Samuel Mize <smize@link.com>
wrote:

>Note that I make some comments about the person Mr. Whiting quoted,
>but none about Mr. Whiting.  Some quotations reformatted for length.
>
>Stephen Leake wrote:
>> 
>> Matthew S. Whiting wrote:
>>  ( second hand list of supposed Ada deficiencies )
>...
>> > >*      Ada does not support discriminant unions (which are
>...
>> This is precisely the Ada discriminant record:
>
>Ah, but you can't hand-code the discriminant values.  This makes it
>harder to interface to existing C code, which of course makes C
>fundamentally better.
>
>Besides, you can't load the variable with one type and then read it
>as another type.  In C it's simple and safe, while in Ada it requires
>Unchecked_Conversion, which everyone knows is dangerous.
>

You are being sarcastic here, right?  

If not, I will have to say I disagree.  Unions in C are far from
"safe", and Unchecked_Conversion is certainly not more dangerous than
unions.

[snip]

--
Kenneth W. Sodemann
kwsodema@avistainc.com
http://www.avistainc.com

Re: ada and robots

[Stephen Leake]

Samuel Mize wrote:
> 
> Note that I make some comments about the person Mr. Whiting quoted,
> but none about Mr. Whiting.  Some quotations reformatted for length.
> 
> Stephen Leake wrote:
> >
> > Matthew S. Whiting wrote:
> >  ( second hand list of supposed Ada deficiencies )
> ...
> > > >*      Ada does not support discriminant unions (which are
> ...
> > This is precisely the Ada discriminant record:
> 
> Ah, but you can't hand-code the discriminant values.  This makes it
> harder to interface to existing C code, which of course makes C
> fundamentally better.
> 
Um, yes you can; that's what an enumeration representation clause is
for; see RM13.4

> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.

Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)

> -- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
> -- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

-- 
- Stephe

Re: ada and robots

[Robert Dewar]

<<> Besides, you can't load the variable with one type and then read it
> as another type.  In C it's simple and safe, while in Ada it requires
> Unchecked_Conversion, which everyone knows is dangerous.
 
Um, this just means Ada _labels_ unchecked conversion as dangerous. In C
it may be "simple", but it is NOT "safe". (Maybe you forgot a smiley?)>>



Maybe he did not think it needed a smiley :-)

The essence of sarcasm as a form is that you say something ludicrous in
a serious manner, to display just how ludicrous it is (a good example,
Jonathan Swift's "A Modest Proposal").

But it is certainly *amazing* how many people did not automatically
read the sarcasm into this statement.

On the other hand, given some of the posts here, may be it is not so
amazing after all :-) :-)
\

Re: ada and robots

[Jon S Anthony]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10748 bytes --]


In article <33A5D644.37A3@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:

<A request for some answers to a co-workers specific "reasons" for why
Ada is not "efficient">

> vague generalities.  As background, the author of the note below is
> currently quite proficient in C and C++ and formerly programmed in Ada
> (Ada83)

As indicated below, the last claim in this statement is very difficult
to believe.  Certainly the fellow does _not_ know even elementary
level Ada.


> >*      Ada does not support discriminant unions (which are extremely useful,
> >almost required). In fact, discriminant union support is required within the
> >data structures that are used within the [one of our systems] data architecture; >and in fact,

At first I thought he meant UNdiscriminated union - the sort of thing
you often see in C stuff (where there is no field in the struct
denoting at runtime which variant of the union is currently active).


> >some of these issues (using the USE AT construct) but still can not get
> >around certain design issues. For example, if a designer wanted to build a
> >data area that would store strings, booleans, ints, longs, float, and doubles
> >all under one type called MyType (which was defined as a structure that
> >contained a type discriminant, and a union to hold the desired value) and
> >then pass an array of these elements (with mixed types) to a routine for
> >processing� A Ada programmer might as well forget it

But then I read this and realized he really _did_ mean discriminated
union.  This is trivial in Ada (including Ada83) and I've done the
very thing he mentions many times.  Here's a canonical form:

    type My_Type ( Kind : Kind_Type ) is record
        case Kind is
    	    when Stg =>
    		S_Val : String_Ref;
    	    when Bool  =>
    		B_Val : Boolean;
    	    when Int   =>
    		I_Val : Integer;
    	    when Long  =>
    		L_Val : Long_Integer;
    	    when Flt   =>
    		F_Val : Float;
    	    when Dbl   =>
    		D_Val : Long_Float;
        end case;
    end record;

type My_Array_Type is array ( Natural range <> ) of My_Type;

...

function F ( X : My_Array_Type ) return ... is
...
    for I in X'range loop
        case X.Kind is
            when int => ...
        ...
end F;


So, at this point (as you can understand) this person's credibility is
closing in on zero.


> >be of the defined type; yet using the C++ array template, one may store
> >objects of different types into the same array.

This is just plain wrong - even for C++!!!  The only thing letting you
store different type objects into a C++ array is if the type is
somehow polymorphic (NOT the array, but its element type).

A template works (more or less) like a generic in Ada (where a generic
array type could be exported - but there is no good reason to do this
in Ada as it already directly supports arrays).

A typical array template in C++ gives you nothing more than what you
can get in Ada by merely writing:

(a)    type Some_Array_Type is array ( Natural range <> ) of Element_Type;

Then you can write:

    A : Some_Array_Type(0..Get_The_Desired_Size);

    B : Some_Array_Type := Some_Initial_Value;

etc.

So, there is the extra step of giving (a) for each element type - but
then you don't need to write or use a template - which your compiler
probably can't compile anyway and which you will almost certainly get
different results from different compilers (and your arrays will be
more efficient).

If you really want a single polymorphic array type, then make the
element type polymorphic:

    type Object_Type is tagged ...

    type Element_Type is access all Object'Class


> >* Ada does not support conforment arrays. You can not pass an array
> with 5 >elements to a routine one time and then pass an array of 10
> elements the next >because of the typing. This is an extremely
> critical aspect that is extremely >difficult to get around within
> Ada compared with C/C++ or Pascal.

This is outright embarrassing for this person.  This is exactly what
unconstrained arrays give you and you get much more expressivity with
them than with C or C++ or Pascal or many others.  Function F above
shows this very thing in action (this is all _very trivial_ and
elementary Ada forms - i.e., anyone will know this stuff after only a
brief aquaintence with the language).  A trivial example using
Some_Array_Type where Element_Type has an "+" operation defined and an
appropriate Identity_Element (for example, if Element_Type is Integer,
and "+" is regular addition, then Identity_Element is 0):

function Sum ( X : Some_Array_Type ) return Element_Type is
    S : Element_Type := Identity_Elememt;
begin
    for I in X'range loop
        S := S + X(I);  -- Dispatch to correct "+"
    end loop;
    return S;
end Sum;


...
    ... Sum((1, 2, 3, 4));  -- returns 10
    ... Sum(("a", "B", "C", "d"));  -- returns "aBCd"


> >* Ada does not support variable length parameter lists. This is a
> very tacky >aspect of the language, which in turn, causes many more
> lines of code to be >generated to support some functionality that
> requires different data inputs.

This is really silly.  Just use an array of discriminated types and
pass an explicit aggregate:

    -- Call F with varying number of arguments:
    --
    ... F(( (Int, 2), (Flt, Pi), (Stg, "Hi There") ));
    ... F(( (Bool, True), (Dbl, E) ));

You can also use default parameters for this sort of thing and use
named notation:

function X ( Amps : Current_Type := 0.0;  Voltage : Power_Type := ...);

   ... X(Voltage => My_Power);
   ... X(Amps => My_Current, Voltage => Some_Power);


> >printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
> >nForce- %f\n", roll, torque, velocity, force);
> >
> >Ada Code:

This is ridiculous.  "Everybody" knows a) you can make printf in Ada
via overloads of "+" on the data types or b) just write the thing
using the more direct equivalent:

Real Ada code (not strawman rubbish) (Lf is a 1 char string of Ascii.LF):

 Put( Lf & Lf &
     "The roller outputs for Roll(" & Integer'Image(Roll) & ") are:" & lf &
     "Torque-" & Float'Image(torque) & lf &
     "Velocity-" & Float'Image(velocity) & lf &
     "Force-" & Float'Image(force) & lf);

> >for debug would be very nice � And this is a simple example of
> why variable >length parameter lists are so very important. Just
> think if you had a

This is not an example of why variable length parameter lists are
important (I'm not convinced they even _are_ important).  This is just
a silly thing where you want to call an I/O function once.  Trivial
and BFD.


> >Parser() routine that could parse a variable length input list of
> 20 >parameters �, you sure would have a lot of Ada routines for
> each list item to >write and maintain.

No you wouldn't.  Well, if this fellow were hacking it up you might,
but that only shows his own incompetence - not a problem with Ada.


> >* DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a
> superset of CORBA >IDL

DCE IDL is not a superset of CORBA IDL.  It is a different thing
offering similar functionality.


> and offers many complex data types that are essential for low-level,
> >high-performance system applications that are not supported in Ada,
> Java, �

Like what?  Really - this guy does not know what he is talking about.


> >This lack or inability of the language to handle complex data
> structures can >again increase the lines of coding.

What complex data structures?  Discriminated unions?  They are trivial
and hardly "complex".


> >* Interface Packages - Another extremely dangerous issue with Ada
> is the fact >that under certain OS's we may be required to write the
> interface bindings to >vendor routines, and these may not be
> commercially available.

No, this too is wrong.  You can directly access the libraries just
like you would from C/C++.  NOTE: when I say "just like in C/C++"
here, I mean just that.  It will be no more safe or clear than what
you get in those languages.  But then, that is what you would have to
do if using C or C++.  So this is neither a disadvantage nor an
advantage.


> >almost guarantees that we will need C bindings to what OS we're using.

No - just grab the routines you want and use the same low level calls
as you would in C/C++.  The smart thing would be to put this rubbish
in a package body and export an OS _independent_ abstraction (for
which you could plug in various OS dependent bodies) - I've done this
and it's cake.


> >VxWorks may have bindings, but what about pSOS, and other potential OS's. I
> >do not see to many IO vendors supplying Ada routines for the hardware�

Same here.


> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in �

Too bad for this person, they are _all_ in error.  In fact, it seems
clear he does not even understand C++ templates (well, to be fair,
probably nobody really does...)


> And many of them focus around the inability of >the language to
> support complex (but required) data structures and types, as

Like what - discriminated unions??  We've seen he is just plain wrong
about this.


> >well as, the intolerable type scheme. The fact the Ada has the
> following >semantics: USE AT, Unchecked_Conversion,
> Unchecked_Access, and >Unchecked_Deallocation; one might ask why Ada
> needs such dangerous elements >within the language unless they are
> required so that the language can perform >certain tasks (which
> require them).

They are there in order for you to break the type system **IF** you
determine this is really necessary.  And they are specifically ugly in
order to a) call your attention to the fact that something funny is
happening here and b) to in some measure prevent you from willy-nilly
sinking to such low level design at the drop of a hat.


> >There truly are many more serious negatives with Ada programming versus
> >C/C++.

Well - he hasn't managed to come up with even one yet.


> >I think I could go on and on about many different areas that would be

And I suppose this would be a littany of errors as well.


> >Hopefully I have given you enough reasons why Ada is not any programmers

Sorry - he hasn't haven't given _any_!!  In fact, he's given reasons
why using Ada would be a _good_ idea.  Every example this person gives
is _easier_ to do in Ada!!


> >device driver for a simple timer card for NT. I think it would become
> >extremely clear at that point.

Well, if this person is writing it, I would believe it would be
screwed up.  You need a competent Ada person, then it would be obvious
that this too would be a non-issue.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Matthew S. Whiting]

I greatly appreciate Jon's rebuttal.  He was quite specific and included
only minimal name calling.  Likewise Robert Duff's comments were fairly
much to the point.  I'm not sure how to reconcile the disagreement
between Jon and Robert with respect to whether 1.5 of the points made
were legitimate or not, but this provides a good reason for me to study
Ada a little more to make my own judgement.  Robert Dewar's complaint of
lack of source code equating to lack of specificity is noted, but Jon
seemed to have enough detail to provide useful commentary.  And the note
did include SOME source code!  Samuel's sarcasm provides me nothing
useful in my ongoing effort to convince my colleague to give Ada a
deeper evaluation.  Lastly, Stephen's comments are helpful as well.  I
appreciate the time you all took to respond, especially those with
useful responses!  I'm not sure which is worse, the ignorance of many C
and C++ programmers or the arrogance of many Ada programmers...

Matt (a lowly engineering manager trying to get my engineers to use the
best available tools and techniques)

Re: ada and robots

[Samuel Mize]

Matthew S. Whiting wrote:
> Samuel's sarcasm provides me nothing
...
> I'm not sure which is worse, the ignorance of many C
> and C++ programmers or the arrogance of many Ada programmers...

I'd vote for the arrogance of ignorant C/C++ programmers who
post abusive messages on comp.lang.ada.  Sorry if you took the
brunt of my annoyance with other people.

I hope the tone didn't keep you from reading the content.

The difference between Ada and C coding really is often a matter
of attitude: whether you are willing to take time up front to
design, or want to jump right in and code, then take the time
at the end to debug.

I suggest you look over the web sites at the end of the weekly
README: HOW TO GET HELP message.  (The rest of the message is
just netiquette for first-time posters.)

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: ada and robots

[Matthew S. Whiting]

Samuel Mize wrote:
> 
> Matthew S. Whiting wrote:
> > Samuel's sarcasm provides me nothing
> ...
> > I'm not sure which is worse, the ignorance of many C
> > and C++ programmers or the arrogance of many Ada programmers...
> 
> I'd vote for the arrogance of ignorant C/C++ programmers who
> post abusive messages on comp.lang.ada.  Sorry if you took the
> brunt of my annoyance with other people.

I've got skin thicker than most alligators.  :-)
 
> I hope the tone didn't keep you from reading the content.

It did not.  And I did check the new "Ada Can do It!" section at AdaHome
dealing with Ada myths.
 
> The difference between Ada and C coding really is often a matter
> of attitude: whether you are willing to take time up front to
> design, or want to jump right in and code, then take the time
> at the end to debug.

I agree.  Unfortunately, changing the attitudes of people that work for
or with you is typically non-trivial.

Matt

Re: ada and robots

[Jon S Anthony]

In article <33A7427F.6646@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:

> much to the point.  I'm not sure how to reconcile the disagreement
> between Jon and Robert with respect to whether 1.5 of the points made
> were legitimate or not, but this provides a good reason for me to study
> Ada a little more to make my own judgement.

Which of these are you thinking about?  The varying argument list?
Robert is correct - it is not _directly_ supported, but the effect can
be rather simply achieved.  This is something to really watch out for
and why the so called "Dewar Effect" of learning a language's idioms
can be important.  Just because X does not have Y's construct C for
doing Blah doesn't mean that the _effect_ of Blah given by C is not
directly expressible in X.  It typically only means it is expressed
differently.

In any case, your last point is exactly correct - make your own
_informed_ judgement.


> appreciate the time you all took to respond, especially those with
> useful responses!  I'm not sure which is worse, the ignorance of many C
> and C++ programmers or the arrogance of many Ada programmers...

Good question.  Arrogance is certainly more annoying while ignorance
is much more frustrating and difficult to work through.  Probably a
wash...


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: ada and robots

[John G. Volan]

Jon S Anthony wrote:
> 
> In article <33A7427F.6646@epix.net> "Matthew S. Whiting" <whiting@epix.net> writes:
> > I'm not sure which is worse, the ignorance of many C
> > and C++ programmers or the arrogance of many Ada programmers...
> 
> Good question.  Arrogance is certainly more annoying while ignorance
> is much more frustrating and difficult to work through.  Probably a
> wash...

Ignorance is far worse than arrogance.  According to the ancient Greeks,
arrogance (i.e., hubris) sooner or later destines you to a tragic
downfall (i.e., "tragic" in the classical sense of "due to a flaw in
your own character").  Whereas, "against ignorance, the gods themselves
contend in vain."

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Robert A Duff]

In article <33A7427F.6646@epix.net>,
Matthew S. Whiting <whiting@epix.net> wrote:
>...  I'm not sure how to reconcile the disagreement
>between Jon and Robert with respect to whether 1.5 of the points made
>were legitimate or not, ...

Well, I guess I was being generous.  The ".5" was for "variable length
argument lists".  I was admitting that they can be a nice convenience.
However, I must say that I completely reject the idea that C in
particular is "better" in this regard, since it sacrifices type checking
for variable length argument lists.  And since you can conveniently
concatenate strings for output, the printf example is not compelling.
My position is: it would be nice (a little bit) to have var-length arg
lists, but only if the language did them in a type-safe way.

Anyway, I thought the issue was whether Ada can deal with low-level
programming such as in device drivers.  And the printf example, and
var-length arg lists, have nothing in particular to do with that.

The "1" was for "lack of bindings", and I still agree with your
colleague that this is a problem in choosing Ada.  On the other hand,
it's not *that* bad -- Ada 95 has quite nice facilities for interfacing
to C.

>... but this provides a good reason for me to study
>Ada a little more to make my own judgement.

Good idea.  I'd be interested in hearing what the outcome is --
e.g. whether or not your colleague ever changes his mind, or comes up
with a real example of device-driver-ish code that can't be written
easily in Ada.

- Bob

Re: ada and robots

[Stephen Leake]

Matthew S. Whiting wrote:
 ( second hand list of supposed Ada deficiencies )

> >*      Ada's strong typing does not allow very complex structures to b=
e
> >manipulated and/or used efficiently due to its typing scheme (which in=
 turn
> >causes a programmer to code many more lines of code, or to structure a=

> >particular data set in a ineffective manner, or not at all).

This is not specific enough; for a counter argument, see the Ada Booch
components, at: http://www.rivatech.com:80/booch/

> >*      Ada does not support discriminant unions (which are extremely u=
seful,
> >almost required). In fact, discriminant union support is required with=
in the
> >data structures that are used within the [one of our systems] data arc=
hitecture; >and in fact,
> >are very critical for supporting applications that need to support man=
y data
> >types within a limited memory area. Ada does have some hacks to get ar=
ound
> >some of these issues (using the USE AT construct) but still can not ge=
t
> >around certain design issues. For example, if a designer wanted to bui=
ld a
> >data area that would store strings, booleans, ints, longs, float, and =
doubles
> >all under one type called MyType (which was defined as a structure tha=
t
> >contained a type discriminant, and a union to hold the desired value) =
and
> >then pass an array of these elements (with mixed types) to a routine f=
or
> >processing=85 A Ada programmer might as well forget it=85  Also, I bel=
ieve this
> >is an issue when declaring an object array with Ada95 where all elemen=
ts must
> >be of the defined type; yet using the C++ array template, one may stor=
e
> >objects of different types into the same array.

This is precisely the Ada discriminant record:

type Label_Type is (String, Boolean, Int, Float);

type MyType (Label : Label_Type :=3D String) is record
   case Label is
   when String =3D>
      String_Value : String (1 .. 80);
   when Boolean =3D>
      Boolean_Value : Boolean;
   when Int =3D>
      Int_Value : Integer;
   when Float =3D>
      Float_Value : Float;
   end case;
end record;

These can be stored in an array.
      =

> >*      Ada does not support conforment arrays. You can not pass an arr=
ay with 5
> >elements to a routine one time and then pass an array of 10 elements t=
he next
> >because of the typing. This is an extremely critical aspect that is ex=
tremely
> >difficult to get around within Ada compared with C/C++ or Pascal. More=
over,
> >this functionality is almost required when processing communications p=
ackets
> >that may be variable-sized.

Wrong again; this is precisely what a String is! The Ada terminology is
"unconstrained arrays".

type String is array (POSITIVE range <>) of character;

procedure Put (Item : in String);

> >*      Ada does not support variable length parameter lists. This is a=
 very tacky
> >aspect of the language, which in turn, causes many more lines of code =
to be
> >generated to support some functionality that requires different data i=
nputs.
> >This limitation can greatly effect a programs function (overload) coun=
t due
> >to this limitation. =


This is true. The reason is type safety and run-time simplicity. When
porting GCC to a new processor, one of my biggest problems was getting
variable arguments working; I'm still finding bugs related to this! But
even given a correct implementation, variable argument lists are just
not type safe. Ada provides alternatives that are safe (see MyType
above).

> >*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a super=
set of CORBA
> >IDL and offers many complex data types that are essential for low-leve=
l,
> >high-performance system applications that are not supported in Ada, Ja=
va, =85
> >This lack or inability of the language to handle complex data structur=
es can
> >again increase the lines of coding.

What are the specific types that DCOM requires that (supposedly) cannot
be defined in Ada? This is arguing from ignorance.

> >*      Interface Packages - Another extremely dangerous issue with Ada=
 is the fact
> >that under certain OS's we may be required to write the interface bind=
ings to
> >vendor routines, and these may not be commercially available. And look=
ing at
> >our current IO vendors, they appear to be supplying C/C++ libraries, w=
hich
> >almost guarantees that we will need C bindings to what OS we're using.=

> >VxWorks may have bindings, but what about pSOS, and other potential OS=
's. I
> >do not see to many IO vendors supplying Ada routines for the hardware=85=


This is not an argument against the language itself, but it is relevant.
Currently, there are more bindings available for C; projects that use
Ada will have to write bindings themselves. This will change as Ada
becomes more popular.

A side benefit of writing your own bindings is that you become more
aware of the details of the system you are binding to; this is sometimes
a good thing.

> >
> >
> >Here are just a few items that truly make Ada very ineffective and
> >inefficient to program in =85 And many of them focus around the inabil=
ity of
> >the language to support complex (but required) data structures and typ=
es, as
> >well as, the intolerable type scheme. =


Ada supports all the complex data structures and types that C does;
please give real examples! The fact that one programmer finds the strong
typing "intolerable" does not mean it is not up to the job.

> >The fact the Ada has the following
> >semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
> >Unchecked_Deallocation; one might ask why Ada needs such dangerous ele=
ments
> >within the language unless they are required so that the language can =
perform
> >certain tasks (which require them). Once elements such as these are us=
ed (and
> >they must in many low-level systems programs), the touted type-safe, r=
obust
> >Ada system is no longer=85 but now in the same field as many other lan=
guages.

Yes, Ada has dangerous features; so does C, C++, and any other
real-world language. The point is that proper system design isolates use
of these dangerous features to small sections of code, and hides them
behind well-defined abstractions. Then the full strong typing of Ada
protects the rest of the system. C and C++ cannot do this.

To paraphrase Robert Dewar, the moral of this story is "don't presume to
critique a language you have not used extensively". In this case, the
critiquer appears to not have used Ada at all!
-- =

- Stephe

Re: ada and robots

[Robert A Duff]

In article <33A69E46.3230@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>This is true. The reason is type safety and run-time simplicity. When
>porting GCC to a new processor, one of my biggest problems was getting
>variable arguments working; I'm still finding bugs related to this! But
>even given a correct implementation, variable argument lists are just
>not type safe. Ada provides alternatives that are safe (see MyType
>above).

Variable-length argument lists are not *inherently* un-type-safe.  They
are so in C.  But I can imagine a language in which they are type safe.

Ada doesn't have them because it would complicate the language.

- Bob

Re: ada and robots

[jim granville]

---- Ada & Robots ---
As this thread has diverged to become a language/religion discussion,
I thought some real code, from real applications, might help.

This code is not Ada, but Modula-2 / IEC1131, which are Ada 'subsets'.
( ie are much closer to Ada in style, syntax, and approach, than to C )

For ROBOT applications, Ada is too large to fit in small controllers,
but
Modula-2 has all the TYPE and SCOPE benefits of Ada, and it actually
fits _very well_ on the C51 core - we have REAL CONTROL apps running in
89C1051's, with 1K of FLASH ROM.

Unlike C, M2 has true BOOLEAN types, which overlay well on the C51
Boolean Engine.
A C51 core also struggles to efficently support C's wide use of
pointers.
( commonly seen in C's are 3 byte, run time interpreted, SLOW pointers..
)

All of the below can be coded in M2, C, and Assembler for that matter.
It can just be done quicker, with fewer errors, in Modula-2.
( a good example of a user supplied C error, is below )

Conclusion : Choose the highest level language that will do the job.
It may be Ada, BASIC, C, Clarion, Delphi, Forth, Modula-2, Visual
BASIC...
( or sometimes, even Assembler )

This code fragment in Modula2, is from a MM53200 'Garage Door' style
decoder, coded for a 89C2051.
Total code size, for a self testing receiver, is 227 bytes.

This code uses the BITSET feature of Modula-2, to greate a PACKED
BOOLEAN
ARRAY of 24 Data bits, into 3 BYTES.
   CASE BitTimeL OF
   | OneMIN..OneMAX :
     INCL(RxCODE[RxCtr >> 3],RxCtr);
   | ZeroMIN..ZeroMAX :   (* default is a Zero *)
   ELSE                   (* bad value, so reset *)
    TF0 := TRUE;          (* catch Reset, next pass  *)
    RxCtr := 0;
   END;
   INC(RxCtr);

This code illustrates two methods of loading, one 'collects' BOOLEANs
and
is highly readable, the other uses BINARY format.
 IE := {EA,ET0,ES};
 IE := 2#1001_0010;     (* EA.EC.ET2.ES.ET1.EX1.ET0.EX0 *)

This code is from a DUAL 6 BIT Picket fence D to A converter.
Total code, for Dual DAC is 95 bytes.
It allows appx 33KHz clock rates, and can run as a background DAC.
More, or less, BITS / Channels are easy to add / remove.
Such DACs are highly linear, use just 1 PIN per DAC, and are ideal for
integration to control voltage outputs.

 DACaPIN := DACa;
 DACbPIN := DACb;
 (* does ONE of these IF statements ONLY *)
 IF PWM.0 THEN          (* 32 Pickets, odd numbers *)
  DACa := DAC_A.5;      (* Uses BYTE BITADDRESSABLE syntax *)
  DACb := DAC_B.5;
 ELSIF PWM.1 THEN       (* 16 Pickets xxxx10 *)
  DACa := DAC_A.4;
  DACb := DAC_B.4;
 ELSIF PWM.2 THEN       (*  8 Pickets xxx100 *)
  DACa := DAC_A.3;
  DACb := DAC_B.3;
 .... etc....

This code flips the BIT order in a BYTE, for COMMS protocol usage.
TYPE hT = ARRAY [0..15] OF BYTE;
                   (*  0   1   2  3    4  5   6  7  8 9 A B   C  D  E  F
*)
CONST MirrorTable =
hT(0H,08H,04H,0CH,02H,0AH,6,0EH,1,9,5,0DH,3,0BH,7,0FH);

PROCEDURE MirrorF(Par : SHORTCARD REGISTER_2) : SHORTCARD; (* 16
bytes,14uS *)
BEGIN
   RETURN(ROTATE(MirrorTable[Par AND 0FH],4) OR MirrorTable[Par >> 4]);
END MirrorF;

And here is some C code, doing the same thing...
This compiles, runs, and works - to a point, It has a BUG that appears
ONLY SOMETIMES. Whilst the Modula-2 compiler would have caught this at
compile time, this C user may have to wait until the customer
calls : ' You know, sometimes.... '

const char Inv[] = {0x00,        //  0000 --> 0000
              0x08,        //  0001 --> 1000
              0x04,        //  0010 --> 0100
              0x0c,        //  0011 --> 1100
              0x0a,        //  0101 --> 1010
              0x06,        //  0110 --> 0110
              0x0e,        //  0111 --> 1110
              0x01,        //  1000 --> 0001
              0x09,        //  1001 --> 1001
              0x05,        //  1010 --> 0101
              0x0d,        //  1011 --> 1101
              0x03,        //  1100 --> 0011
              0x0b,        //  1101 --> 1011
              0x07,        //  1110 --> 0111
              0x0f};       //  1111 --> 1111

char Invert(char cByte)
{
   return ((Inv[cByte & 0xf] << 4) | Inv[(cByte & 0xf0)>>4]);
}

- jim granville

-- 
======= Manufacturers of Serious Design Tools for uC and PLD  =========
= Optimising Modula-2 Structured Text compilers for ALL 80X51 variants
= Reusable object modules, for i2c, SPI and SPL bus interfaces
= Safe, Readable & Fast code - Step up from Assembler and C
= Emulators / Programmers for ATMEL 89C1051, 2051, 89C51 89S8252 89C55
= *NEW* Bondout ICE for 89C51/89C52/89C55 
= for more info, Email : DesignTools@xtra.co.nz  Subject : c51Tools

Re: ada and robots

[Robert Dewar]

Jim Granville posts a useful example in Modula. This will translate
very clearly and straightforwardly into Ada (I am sure someone here
will post the translation :-) so I am a little puzzled at Jim's claim
that Ada is somehow unsuitable for this task -- I guess it must just
come from knowing Modula better than Ada :-)\

Re: ada and robots

[Matthew Heaney]

In article <33AAC183.34C0@xtra.co.nz>, DesignTools@xtra.co.nz wrote:

I'm not a Modula programmer; perhaps you can walk me through some of your
code examples.

>This code uses the BITSET feature of Modula-2, to greate a PACKED
>BOOLEAN
>ARRAY of 24 Data bits, into 3 BYTES.

This can be done in Ada.

type Bit_Array is 
   array (Positive range 0 .. 23) of Boolean;

for Bit_Array'Size use 24;
for Bit_Array'Component_Size use 1;

or in this case you could just

pragma Pack (Bit_Array);

Ada guarantees that for an array for which the component size is 1 (and
type Boolean is guaranteed to be size 1), that array components are aligned
on contiguous bits.

>   CASE BitTimeL OF
>   | OneMIN..OneMAX :
>     INCL(RxCODE[RxCtr >> 3],RxCtr);
>   | ZeroMIN..ZeroMAX :   (* default is a Zero *)
>   ELSE                   (* bad value, so reset *)
>    TF0 := TRUE;          (* catch Reset, next pass  *)
>    RxCtr := 0;
>   END;
>   INC(RxCtr);

Can you explain what's going on here?

INCL means add an item to a set, right?   If so, you just set the
corresponding bit of the bit array to True.

Of course, we could declare a full-blown set abstract data type,
implemented as a bit array, but when you're twiddling bits anyway, one
doesn't usually bother.

>This code illustrates two methods of loading, one 'collects' BOOLEANs
>and
>is highly readable, the other uses BINARY format.
> IE := {EA,ET0,ES};
> IE := 2#1001_0010;     (* EA.EC.ET2.ES.ET1.EX1.ET0.EX0 *)

type Bit_Array_Range is (EA, EC, ET2, ES, ET1, EX1, ETO, EXO);
type Bit_Array is array (Bit_Array_Range) of Boolean;
pragma Pack (Bit_Array);

To do the first, you can use aggregate assignment:

IE : Bit_Array := (EA, ETO, ES => True, others => False);

To do the second, you have to use unchecked conversion:

function To_Bit_Array is
   new Unchecked_Conversion (
      Source => Interfaces.Unsigned_8, 
      Target => Bit_Array);

IE : Bit_Array := To_Bit_Array (2#1001_0010#);

Oh well, an extra line of code, to do the instantiation.

>This code is from a DUAL 6 BIT Picket fence D to A converter.
>Total code, for Dual DAC is 95 bytes.
>It allows appx 33KHz clock rates, and can run as a background DAC.
>More, or less, BITS / Channels are easy to add / remove.
>Such DACs are highly linear, use just 1 PIN per DAC, and are ideal for
>integration to control voltage outputs.

>  DACa := DAC_A.5;      (* Uses BYTE BITADDRESSABLE syntax *)

If you mean get at an individual bit, that can be done if the type is
already declared as a bit array, or else using unchecked_conversion to a
bit array.

   DAC_A (5)

or

  To_Bit_Array(DAC_A)(5)

You may need an extra pair of parens here; I don't have my Ada 95 compiler
handy.


>This code flips the BIT order in a BYTE, for COMMS protocol usage.
>TYPE hT = ARRAY [0..15] OF BYTE;
>                   (*  0   1   2  3    4  5   6  7  8 9 A B   C  D  E  F
>*)
>CONST MirrorTable =
>hT(0H,08H,04H,0CH,02H,0AH,6,0EH,1,9,5,0DH,3,0BH,7,0FH);
>
>PROCEDURE MirrorF(Par : SHORTCARD REGISTER_2) : SHORTCARD; (* 16
>bytes,14uS *)
>BEGIN
>   RETURN(ROTATE(MirrorTable[Par AND 0FH],4) OR MirrorTable[Par >> 4]);
>END MirrorF;

type hT is array (0 .. 15) of Unsigned_8;
 -- we may have to declare the array index subtype as a modular type
 -- ie type hT is array (Unsigned_8) of Unsigned_8;
 -- but I've never done that, and I don't have my compiler handy...

Mirror_Table : constant hT := 
 (16#0#, 16#8#, ...);

function Mirror_F (Par : Unsigned_8) return Unsigned_8 is
begin
   return Rotate_Right (Mirror_Table (Par and 16#0F#), 4) or
                 Mirror_Table (Shift_Right (Par, 4));
end;

or something like that. 

If my knowledge of Modula were better (I only have Wirth's book, which I
haven't even read), there might be a slicker Ada way to do this, instead of
as a straight translation.

The point is, however, that Ada is no less expressive than Modula with
respect to its low-level facilities.  Nor do I suppose its code generation
is any less efficient, if the types in package Interfaces are used.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Matthew Heaney wrote:
> 
> Of course, we could declare a full-blown set abstract data type,
> implemented as a bit array, 

A type providing sets of small integers is quite remote from "a 
full-blown set abstract data type"; the confusion can be traced to the
Pascal influence. If you want to see a language with "a full-blown set
abstract data type", look a SETL, whic I understand was the original 
implimentation language for GNAT.

> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[Robert Dewar]

<<

A type providing sets of small integers is quite remote from "a

full-blown set abstract data type"; the confusion can be traced to the

Pascal influence. If you want to see a language with "a full-blown set

abstract data type", look a SETL, whic I understand was the original

implimentation language for GNAT.>>


This is a miscconception, GNAT was always written
in Ada (first in Ada 83, later more and more Ada 95 features were used).

The confusion is with an earilr compioler  Ada/Ed, which was a quite separate effort.

Re: ada and robots

[Robert A Duff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7510 bytes --]


In article <33A5D644.37A3@epix.net>,
Matthew S. Whiting <whiting@epix.net> wrote:
>Robert Dewar wrote:
>> 
>> I asked Joe for specific code, ...

>I'm not Joe, but I've been having a similar line of, shall we say,
>"discussion" with a colleague where I work.  Here's his reply when I
>asked for specific issues that C or C++ could easily handle that were
>difficult or impossible to handle in Ada.  

Still not specific.  Robert asked for specific C code, and we still
haven't seen any.  Your colleague gives us (1) vague generalities, and
(2) misinformation.

>>*      Ada's strong typing does not allow very complex structures to be
>>manipulated and/or used efficiently due to its typing scheme (which in turn
>>causes a programmer to code many more lines of code, or to structure a
>>particular data set in a ineffective manner, or not at all). 

This is an example of (1).  You should insist that your colleague show
the C code for at least one such example.  Only *then* can we argue
about whether Ada can't do it, or can't do it well.  From the above, I
have no idea what he's talking about.

>>*      Ada does not support discriminant unions (which are extremely useful,
>>almost required). In fact, discriminant union support is required within the
>>data structures that are used within the [one of our systems] data architecture; >and in fact,
>>are very critical for supporting applications that need to support many data
>>types within a limited memory area. Ada does have some hacks to get around
>>some of these issues (using the USE AT construct) but still can not get
>>around certain design issues. For example, if a designer wanted to build a
>>data area that would store strings, booleans, ints, longs, float, and doubles
>>all under one type called MyType (which was defined as a structure that
>>contained a type discriminant, and a union to hold the desired value) and
>>then pass an array of these elements (with mixed types) to a routine for
>>processing� A Ada programmer might as well forget it�  Also, I believe this
>>is an issue when declaring an object array with Ada95 where all elements must
>>be of the defined type; yet using the C++ array template, one may store
>>objects of different types into the same array.

Ada *does* have discriminated unions, and can do the above (passing
array, blah blah blah).  The only problem I can see here is that Ada
insists that the discriminant be part of the object, whereas some
hardware-defined data structures encode the "discriminant" in weird
ways.

>>*      Ada does not support conforment arrays. You can not pass an array with 5
>>elements to a routine one time and then pass an array of 10 elements the next
>>because of the typing. ...

This is so vastly wrong (for both Ada 83 and Ada 95) that I have a hard
time believing that your colleague ever wrote an Ada program.  I mean,
the simplest "Hello, world" program in Ada uses this feature -- how
could he have missed it?

>>*      Ada does not support variable length parameter lists.

Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
with why C is better or worse at accessing low-level hardware
functionality.  It was left out of Ada to simplify the language.

>... This is a very tacky
>>aspect of the language, which in turn, causes many more lines of code to be
>>generated to support some functionality that requires different data inputs.
>>This limitation can greatly effect a programs function (overload) count due
>>to this limitation. For example, lets look at the following simple
>>non-critical I/O code:
>>
>>C Code: 
>>
>>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
>>nForce- %f\n", roll, torque, velocity, force);
>>
>>Ada Code:
>>
>>Ada.Text_IO.New_Line(2);
>>Ada.Text_IO.Put("The roller outputs for Roll[");
>>Ada.Int_IO.Put(roll);
>>Ada.Text_IO.Put("] are:");
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Torque-");
>>Ada.Real_IO.Put(torque);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Velocity-");
>>Ada.Real_IO.Put(velocity);
>>Ada.Text_IO.New_Line;
>>Ada.Text_IO.Put("Force-");
>>Ada.Real_IO.Put(force);
>>Ada.Text_IO.New_Line;

In Ada, I would write something like this:

    use Ada.Text_IO;
    ...
    New_Line(2);
    Put_Line(" The roller outputs for Roll[" & Image(Roll)
             & "] are:");
    Put_Line(" Torque-" & Image(Torque));
    Put_Line(" Velocity-" & Image(Velocity));
    Put_Line(" Force-" & Image(Force));

Given suitable Image functions (which I always define), or else use the
standard 'Image attribute.  We can argue about whether this is better or
worse than the corresponding C code, but it's nowhere near as bad as
the Ada code your colleague wrote.  I claim my Ada code is far better
than the C code, since it does type checking.

>>I don't think a lot of debug text I/O to a VT320 screen included in a system
>>for debug would be very nice � And this is a simple example of why variable
>>length parameter lists are so very important. Just think if you had a
>>Parser() routine that could parse a variable length input list of 20
>>parameters �, you sure would have a lot of Ada routines for each list item to
>>write and maintain.

I agree that variable-length parameter lists are a nice convenience.
However, your colleague is wrong: in Ada, you would *not* have 20
overloadings here -- you would have a procedure that takes a single
parameter of some sort of array or sequence type.

>>*      DCOM (which OPC will be based) uses DCE IDL. DCE IDL is a superset of CORBA
>>IDL and offers many complex data types that are essential for low-level,
>>high-performance system applications that are not supported in Ada, Java, �
>>This lack or inability of the language to handle complex data structures can
>>again increase the lines of coding.

I don't know DCE IDL enough to comment.

>>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
>>that under certain OS's we may be required to write the interface bindings to
>>vendor routines, and these may not be commercially available.

Granted.  This is a problem with using Ada.

>>Here are just a few items that truly make Ada very ineffective and
>>inefficient to program in � And many of them focus around the inability of
>>the language to support complex (but required) data structures and types, as
>>well as, the intolerable type scheme. The fact the Ada has the following
>>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
>>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
>>within the language unless they are required so that the language can perform
>>certain tasks (which require them). Once elements such as these are used (and
>>they must in many low-level systems programs), the touted type-safe, robust
>>Ada system is no longer� but now in the same field as many other languages.

This is a bogus argument.  Just because one part of a program uses a
low-level features like Unch_Conv, doesn't mean that *all* of the
benefits of Ada are lost to the *entire* program.

>>There truly are many more serious negatives with Ada programming versus
>>C/C++.

I count one and a half in the above.  So lets see the "many more".

Again, let's see the C.  Real code.  Ask your colleague to show us some
C code (for a device driver, or part of one, for example), and let's see
whether Ada is up to the job.  I will freely admit that Ada has many
flaws, but the above series of incorrect claims about Ada doesn't help.

- Bob

Re: ada and robots

[Ken Garlington]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]


Robert A Duff wrote:
> 
> >>*      Ada does not support variable length parameter lists.
> 
> Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
> with why C is better or worse at accessing low-level hardware
> functionality.  It was left out of Ada to simplify the language.

Well, in fact it does (from the client perspective) because of
overloading.
DEC Ada uses this extensively in their libraries. Yes, it requires more
lines of code when writing the object, but no additional lines of code
to call it. Therefore, it's just as convienient... unless you're just
hacking
some code together, of course.

> >>*      Interface Packages - Another extremely dangerous issue with Ada is the fact
> >>that under certain OS's we may be required to write the interface bindings to
> >>vendor routines, and these may not be commercially available.
> 
> Granted.  This is a problem with using Ada.

However, it's not an "extremely dangerous" issue, particularly given
automated C-to-Ada
conversion. It may be a productivity issue, at best.

> 
> >>Here are just a few items that truly make Ada very ineffective and
> >>inefficient to program in � And many of them focus around the inability of
> >>the language to support complex (but required) data structures and types, as
> >>well as, the intolerable type scheme. The fact the Ada has the following
> >>semantics: USE AT, Unchecked_Conversion, Unchecked_Access, and
> >>Unchecked_Deallocation; one might ask why Ada needs such dangerous elements
> >>within the language unless they are required so that the language can perform
> >>certain tasks (which require them). Once elements such as these are used (and
> >>they must in many low-level systems programs), the touted type-safe, robust
> >>Ada system is no longer� but now in the same field as many other languages.
> 
> This is a bogus argument.  Just because one part of a program uses a
> low-level features like Unch_Conv, doesn't mean that *all* of the
> benefits of Ada are lost to the *entire* program.

Presumably, any "C" routine that calls assembly code loses all of the
benefits of
a higher-order language, by the same reasoning.

> Again, let's see the C.  Real code.  Ask your colleague to show us some
> C code (for a device driver, or part of one, for example), and let's see
> whether Ada is up to the job.  I will freely admit that Ada has many
> flaws, but the above series of incorrect claims about Ada doesn't help.

Let's do the opposite: Write an assembly program that can't be coded in
C (or other high-order language), and use that to show that we must all
code in assembly. How about: Do a ones-and-zeros ripple test
of all of memory, including the stack and heap.

> 
> - Bob

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
Who uses Ada? See http://www.lmasc.lmco.com/f22
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: ada and robots

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:
> 
> > Again, let's see the C.  Real code.  Ask your colleague to show us some
> > C code (for a device driver, or part of one, for example), and let's see
> > whether Ada is up to the job.  I will freely admit that Ada has many
> > flaws, but the above series of incorrect claims about Ada doesn't help.
> 
> Let's do the opposite: Write an assembly program that can't be coded in
> C (or other high-order language), and use that to show that we must all
> code in assembly. How about: Do a ones-and-zeros ripple test
> of all of memory, including the stack and heap.

As a sidelight, I was once tasked with improving the performance of a
service routine written in Intel assembly language; my replacement
version was in Ada and was dramatically faster. This doesn't prove that
Ada is more efficient than assembly language, but rather that there is a
lot more to efficiency than just the choice of language.

> --
> LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
> Who uses Ada? See http://www.lmasc.lmco.com/f22
> For job listings, other info: http://www.lmtas.com or
> http://www.lmco.com

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz.

Re: ada and robots

[Robert Dewar]

Bob Duff wrote

(regarding variable length parameter lists in Ada, lack thereof)

<<Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
with why C is better or worse at accessing low-level hardware
functionality.  It was left out of Ada to simplify the language.
 

I disagree, there are two issues here. Variable length lists of homogenous
types (which can include of course collectoins of pointers to different
subtype instances of a class) can perfectly well be passed. For example,
a routine called put_lines that outputs a series of lines can be called

put_lines (("line1", "line2", "line3"));

This kind of "implicit rowing" first appeared in Algol68, and is a very
convenient way of dealing with variable length parameter lists.

However, what the C folks might want is the completely general capability
for variable length lists of arbitrary heterogenous types. This is possible
in C, but is seriously type unsafe. Furthermore, there is no obvious way it
can be made type safe. Hence this feature definitely should be rejected, as
should any programmer who feels they cannot program without it.

To be fair, it is possible to get something like this by means of an implicit
uniting coercion, but it is really very little trouble to introduce this
explicitly.

So for example, suppose you want a routine that takes an arbitrary list
of integers and floats (could obviously be extended), then you could make
a routine in Ada that looked like

  printf ("the value of x is % and the value of y is %",
            (I(integer expr), F(float expr)));

which seems close enough to the C notation if this is really what you want.

Re: ada and robots

[Adam Beneschan]

bobduff@world.std.com (Robert A Duff) writes:

 >>>*      Ada does not support variable length parameter lists.
 >
 >Granted.  IMHO, a "nice to have" feature, but certainly nothing to do
 >with why C is better or worse at accessing low-level hardware
 >functionality.  It was left out of Ada to simplify the language.

I haven't been following this thread, so my apologies if I post
something that duplicates something someone else has written.

I don't miss having variable length parameter lists, because there are
a couple easy ways to accomplish practically the same thing.  One
technique is to declare a routine something like this:

    function Build_String (Input1, Input2, Input3, Input4, 
                           Input5, Input6, Input7, Input8 : String := "")
                return String;

Now, I have a way to make variable-length parameter calls, up to eight
parameters:

    Text_IO.Put_Line (Build_String ("a", "b"));
    Text_IO.Put_Line (Build_String ("a", "b", "c", "d", "e"));

etc.  (Of course, this type of solution assumes that you'll never
legitimately want to use "" as a parameter.)

Another solution, which works better if the parameter types are
scalars, is to use an array as a parameter.  I've written code like
this: 

    type Option_Type is (Allow_Hex, Allow_Underscore,
                         No_Decimal_Point, ...)
    type Option_Array is array (natural range <>) of Option_Type;
    procedure Parse_String (Source  : in string;
                            Options : in Option_Array;
                            etc.)

and now I can call

    Parse_String (S, (Allow_Underscore, No_Decimal_Point));
    Parse_String (S, (Allow_Underscore, No_Decimal_Point, Allow_Hex));

putting as many options as I like in the array parameter.  (C doesn't
allow you to create an in-line array like this to pass to a function,
or even to assign to an array variable.  In fact, I'm surprised the
anti-Ada poster gave us something like

 >>>C Code: 
 >>>
 >>>printf("\n\n The roller outputs for Roll[%d] are:\n Torque-%f\nVelocity-%f\
 >>>nForce- %f\n", roll, torque, velocity, force);
 >>>
 >>>Ada Code:
 >>>
 >>>Ada.Text_IO.New_Line(2);
 >>>Ada.Text_IO.Put("The roller outputs for Roll[");
 >>>Ada.Int_IO.Put(roll);
 >>>Ada.Text_IO.Put("] are:");
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Torque-");
 >>>Ada.Real_IO.Put(torque);
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Velocity-");
 >>>Ada.Real_IO.Put(velocity);
 >>>Ada.Text_IO.New_Line;
 >>>Ada.Text_IO.Put("Force-");
 >>>Ada.Real_IO.Put(force);
 >>>Ada.Text_IO.New_Line;
  
when it's so easy to answer:

C code:

   array_variable[0] = 7;
   array_variable[1] = x + 1;
   array_variable[2] = x + 2;
   array_variable[3] = (x - y) % 5;
   array_variable[4] = -3;

Ada code: 

   Array_Variable := (7, X + 1, X + 2, (X - Y) mod 5, -3);

)

I've even used this technique to write an Ada 83 version of printf().
Of course, you can't declare an array whose elements aren't the same
type, but all you have to do is declare a variant record type that
could hold any type you would want to output:

    type String_P is access string;
    type Data_Type is (V_Integer, V_Float, V_String);
    type Heterogeneous_Data (DType : Data_Type) is record
        case Dtype is
            when V_Integer =>   Int_Data    : Integer;
            when V_Float   =>   Float_Data  : Float;
            when V_String  =>   String_Data : String_P;
        end case;
    end record;

Now, declare an overloaded function that converts any data type to
Heterogeneous_Data.  Some people like overloading unary "+" for this.
Declare an array of Heterogeneous_Data, and use it as the parameter to
your Printf.  This does take some code to set up, but once it is, you
can use it easily:

    Printf ("\n\n The roller outputs for Roll[%d] are:" & 
                "\n Torque-%f\nVelocity-%f\nForce- %f\n",
            (+Roll, +Torque, +Velocity, +Force));

and voila, a Printf that's actually capable of checking the types,
something that C's printf() doesn't do well.  (The object-oriented
features of both Ada 95 and C++ provide ways to handle heterogeneous
data like that more cleanly.)  I used to use a Printf routine like
this, until I found that writing code like Bob's:

 >In Ada, I would write something like this:
 >
 >    use Ada.Text_IO;
 >    ...
 >    New_Line(2);
 >    Put_Line(" The roller outputs for Roll[" & Image(Roll)
 >             & "] are:");
 >    Put_Line(" Torque-" & Image(Torque));
 >    Put_Line(" Velocity-" & Image(Velocity));
 >    Put_Line(" Force-" & Image(Force));

was easier to read and maintain, in my opinion.  This is an option we
Ada programmers have, since we have a string concatenation operator.

Just my contribution to the holy wars . . .

                                -- Adam

Re: ada and robots

[Robert Dewar]

Matthew Whiting's anonymous friend once again posts a whole bunch of reasons
why Ada cannot be used to do marvellous things. Of course a lot of these
points are just technically misinformed (the nonsense about conformant
arrays stands out particularly, but also the business about printf seems
a bit pathetic too).

But what is really annoying is that once again, we have vague uninformed
statements, which we could correct, but that is not what we asked for,
we asked for a piece of representative code.

The really convincing argument that these "let-me-alone-and-write-in-C"
[reminds me of Hacker's Senior's lyrics in The Maiden and the Mandate, but
that was in fun :-)] could provide is

   *CODE*

that we could look at, and agree, yes, hmmm! indeed that would be tough to
do in Ada, we see what you mean.

But none of these guys seem willing to actually provide such!

Re: ada and robots

[RC]

In <33930245.12A1@sprintmail.com> by "John G. Volan"
<johnvolan@sprintmail.com>
>Dale Stanbrough wrote:
>> 
>> John Cook writes:
>> 
>> "small systems a student can afford"
>>         The Meridian Ada compiler, which comes for free with a book, is rather
>>         cheap, and targets any of the 8086 family (which are cheap, no?).
>>         It is Ada83 however. So I think you agree with you.
>
>Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
>near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
>for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
>of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
>it does let you write standalone Mac apps in Ada.)

Isn't this written in C?  Seems a bit defeatist.

RC1

Re: ada and robots

[John G. Volan]

RC wrote:
> 
> In <33930245.12A1@sprintmail.com> by "John G. Volan"
> <johnvolan@sprintmail.com>
> >Come now, don't tell me you haven't heard of GNAT? [snip]
> 
> Isn't this written in C?  Seems a bit defeatist.

Before you go perpetuating myths, get your facts straight. GNAT is
written in Ada95, and compiles itself.  It is one of several language
front-end modules (including C, C++, Modula3, and Fortran) that are
plugged into GCC's multi-language optimizing back-end code-generation
system, which was indeed written in C.  Sounds to me like an excellent
example of mixed-language programming and reuse.

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[Larry Kilgallen]

In article <ytxyoLAxaYlzUw5R@clanchy.demon.co.uk>, RC <rc1@clanchy.demon.co.uk> writes:
> In <33930245.12A1@sprintmail.com> by "John G. Volan"
> <johnvolan@sprintmail.com>

>>Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
>>near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
>>for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
>>of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
>>it does let you write standalone Mac apps in Ada.)
> 
> Isn't this written in C?  Seems a bit defeatist.

1. Not exactly.

2. To insist that all products one uses be written a particular
   language narrows the field considerably.  When choosing a
   compiler I would be guided by past experience of others more
   that the theoretical probability of a certain number of defects.
   For choosing an airplane run by computer my emphasis would change.

Larry Kilgallen

Re: ada and robots

[Jon S Anthony]

In article <ytxyoLAxaYlzUw5R@clanchy.demon.co.uk> RC <rc1@clanchy.demon.co.uk> writes:

> >Come now, don't tell me you haven't heard of GNAT?  It runs on pretty
> >near everything (UNIX, DOS, Wintel, even Mac).  And you can download it
> >for free.  (Well, on a Mac you have to spend $99 to get Machten, a port
> >of BSD Unix that runs as a Mac app, but then you get GNAT for free. And
> >it does let you write standalone Mac apps in Ada.)
> 
> Isn't this written in C?  Seems a bit defeatist.

No.  Isn't spouting off without checking any facts, irresponsible
behavior?

> RC1

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: ada and robots

[Nick Roberts]

Tom Moran <tmoran@bix.com> wrote in article <338F9D05.5EB3@bix.com>...
> > K&R wanted a portable
> > assembly language with a rich set of operators  and minimal constraints
> > so they invented C
>   How many people still use K&R C?  Would you call C++ a portable
> assembly language?


I think I'd go further and suggest that a higher level language than Ada
might be more suitable to your purpose (depending on what you are really
trying to do). Are you familiar with Prolog or Lisp? There are many
different robotics-specific languages, also. You may even find that using a
programming language of any kind is not what you require (perhaps an
adaptive learning system implemented at hardware level would work better).
What are you trying to achieve, ultimately?

Nick.

Re: ada and robots

[Jan Galkowski]

Nick Roberts wrote:
> 
[snip]

> 
> I think I'd go further and suggest that a higher level language than Ada
> might be more suitable to your purpose (depending on what you are really
> trying to do). Are you familiar with Prolog or Lisp? There are many
> different robotics-specific languages, also. You may even find that using a
> programming language of any kind is not what you require (perhaps an
> adaptive learning system implemented at hardware level would work better).

I agree with Nick.  Although lowest level control of motors
and sensors might well be done with C++, as well as calculations
which just have to be fast, things like motion planning, force
feedback, assembly planning, interpretation of touch fields are
all things that cry for higher order implementation.  

A characteristic of assembly control is that one needs to consider
that every action one tries may fail, and plan a backup route for
it.  Thus, if this were done in Ada, you'd put a failure handler
with a different body about each and every motion statement.
This is verbose. 

I've never used it for robot programming, even in a pretending
way, but I've often thought Icon, with its builtin treatment of
failures, might be a good thing to use.

> What are you trying to achieve, ultimately?

Yes, definitely: "Robot programming" isn't a monolithic application.
There are the hobbyists robots, there are the relatively 
unintelligent repetition-based robots for which no programming
language is suitable (programmed by motion macros), and then
there are sophisticated systems which try mechanical assemblies.

>

[snip]
-- 
 Jan Theodore Galkowski, 
 developer, statistician,
   Digicomp Research Corporation,
   Ithaca, NY 14850-5720
 jan@digicomp.com 
 (also jtgalkowski@worldnet.att.net)

Re: ada and robots

[Albert K. Lee]

So does anybody have any answers for the original poster?  That guy
who was asking quite innocently about specific techniques and tools
for embedded programming using the Ada language?

I am interested as well and would rather see answers than read thru
incessant language wars.


-Albert

Re: ada and robots

[dana]

In article <slrn5pch85.avm.aklee@bonsai.net>, aklee@no_spam.bonsai.net
(Albert K. Lee) wrote:

> So does anybody have any answers for the original poster?  That guy
> who was asking quite innocently about specific techniques and tools
> for embedded programming using the Ada language?
> 
> I am interested as well and would rather see answers than read thru
> incessant language wars.
> 
> 
> -Albert

I think the general lack of response back to the group could be taken as
response in the negative.  I e-mail the original poster with a more
detailed response but I'll post a summary here for all you curious folks. 


I assume the original question was REALY about looking for compilers for
the calss of low cost 8 -16 bit processors typically used in hobbyist type
robots.  ("Hobbyist", not to demean these robots, just classify them) 
That question raises several other on obvious questions.  

1)    Q:  are there any Ada compilers for 8051s, PIC-1X's, 6502, 80C196KB,
etc micro controllers?

      A:  No, or at least not many.  It's hard to put an exact reason as
to why but it is thought that these MCs are just "too small" in terms of
address space etc to support a multitasking language/runtime.  Hello world
generated by DDCI's sun cross 80386EX compiler is JUST under 16k with the
non-tasking runtime.  I've seen similar performance from other Ada
compilers.  The whole answer is much longer but has been discussed at
length in this group.  Now, that being said, it is still worth a check of
adahome to see what the vendors have.  I could be wrong.  It wouldn't be
the first time:-)


2)    Q:  Is Ada used in robotics?  This is a question several occasional
posters to this group could have answered.  But the answers weren't
exactly what the original poster was looking for.  Robotics is a vary
broad field ranging from little critters skittering about on the floor
with 8 bit micro controllers to large kinematically redundant manipulator
mechanisms with multiple 32 bit high performance processors.  

      A:  Yes and No.  No, due to the use of 8-16 bit MCs in critterbots,
Ada is _probably_ not a good candidate for them.  But with the falling
cost and power requirements and the fact that 1M of RAM could be purchased
with the change on the floor of my mini van, I think a 32 bit MC could be
used in criterbots very soon.  Yes, the former robot lab at goddard space
flight center, as well as at least one robot lab at NIST controlled their
robots with 25Mhz 386/387's running software written in Ada.  These
research efforts are long gone in history.   I participated in the effort
at GSFC.  I also worked on a more recent effort where robot applications
were written in C++, running on LynxOS running on Pentiums.  

As another poster stated, "good or poor software can be written in any
language".  Quite true.  The individual programer and project probably
have a greater impact at this level.  I however have written robot control
software in C, C++, and Ada and from my personal anicdotal experience, my
C had the lowest productivity in terms of functionality per time period,
and the highest rate of flaws found per function.  My C++ just nosed out
my Ada83 in apparent productivity per time period BUT had a much higher
flaw rate and the flaws were much more difficult to remove than the Ada83
flaws.  Debugging large systems by rummaging through the entrails of core
dumps is VERY slow.  The few cases where I have seen C/C++ head to head
with Ada on the same or similar projects, the post release flaw rate was
where C/C++ got murdered.  They did usually beat the Ada implementation in
productivity.  But this is starting to sound like a language war.  

The SEI (software engineering institute) CMM (capability maturity model),
as I interpret it, seems to indicate that intelligent language selection
is an activity of VERY mature software organizations (wouldn't switching
languages, however, seem like an immature undertaking?) because of the
long term historical data needed to spot deficiencies in languages.  It's
easy to look over a language like Ada, C, C++, Java and say "Language X
will be the BEST to write robot code!" Being correct in this is quite a
bit trickier.  Sometimes library availability drives this decision.  I'm
still looking for the deffinitive answer on how immature organizations
should choose programming languages.  

Where one stands on this issue, also depends quite a lot on where one used
to sit!  If _I_ were to write robot controller software, and _I_ could
choose the language, I would dig out my old 9-tracks tapes of Ada robot
library code and catapult myself and my project ahead by many thousands of
lines of tested re-useable code.  Other, not so lucky people, might not
have millions of dollars worth of public domain code on a tape in their
closet (-8-0).  When I suggested that by choosing Ada we might save
whopping large amounts of time and money with reuse to a former employer,
they looked at me like a bug.  

The original poster also mentioned how Ada was designed to be targeted at
the "embedded market".  I think this causes some confusion.  The "Embedded
market" ranges from small 2kbyte programs, writte in assembler, running on
microcontrollers, to megga-line projects distributed across hundreds of
processors controlling life and mission critical activities.  Ada was
targeted towards the traditional "medium to large" projects.  I think this
is where DOD was getting their butts kicked with cost overruns, schedule
slips and project failures.  

It's a question of scale.  One guy banging out ASM can handle a simple
programming project.  There are lots of personal electronic and other
devices successfully brought to market with this approach and thats just
fine for them.  The disaster occurs when the "one dude hacking" model is
scaled up to larger projects.  This sort of thing is the nucleus for many
books on software project management.  Which would be a good point to
depart from this discussion.

Re: ada and robots

[John G. Volan]

dana@indyweb.net wrote:
> 
> In article <slrn5pch85.avm.aklee@bonsai.net>, aklee@no_spam.bonsai.net
> (Albert K. Lee) wrote:
> 
> > So does anybody have any answers for the original poster?  That guy
> > who was asking quite innocently about specific techniques and tools
> > for embedded programming using the Ada language?
[snip]
> I think the general lack of response back to the group could be taken as
> response in the negative.  

I dunno. This newsgroup has been uncharacteristically quiet lately, the
usual contributors seem to have dropped off the map. Is there some Ada
conference going on this week? 

> I e-mail the original poster with a more
> detailed response but I'll post a summary here for all you curious folks.
> 
> I assume the original question was REALY about looking for compilers for
> the calss of low cost 8 -16 bit processors typically used in hobbyist type
> robots.  ("Hobbyist", not to demean these robots, just classify them)
> That question raises several other on obvious questions.
... 

Dana's points are well-taken, but let me steer the discussion slightly
into a different avenue: If we're talking "hobbyist" category work, then
what about GNAT?

If any of the GNAT team are listening, I'll defer to their wisdom of
course, but in the meantime:

- In the 8-16 bit processor category, when this question has been asked
in the past, the general consensus appears to be that indeed, such
systems are "too small" to port GNAT to.  In fact, I believe 8-bit
processors would be too small for Ada itself (ah, at last, an actual
language-suitability fact!) because, for instance, Standard.Integer is
expected to be optimally supported on the given target hardware, and it
is required to cover at least a 16-bit range of integer values. 
(Doesn't C have a similar requirement for int?)  For 16-bit processors,
I believe Robert Dewar has basically discounted the possibility of
porting GNAT, but I wonder if he just meant that a 16-bit processor is
an unlikely _host_ for GNAT?  It would be worth checking the GCC configs
to see whether your prospective 16-bit target architecture was already
supported there. If it is, then it's not that hard to configure and
build a GNAT cross-compiler for it. If the platform isn't already
supported, doing a fresh port of GCC is somewhat more difficult (you
have to create a description of your target instruction set using
Register Transfer Language, and so forth), but it's not entirely
impossible.

(There's the obvious question about whether tasking can be supported if
you don't already have a threads library for the target platform, but
you may have already decided to jettison tasking anyway. And of course
things such as Text_IO are problematic without OS support.)

- GNAT looks much more feasible for processors in the 32-bit range, and
as Dana points out, the price of these has been falling. Cross-compiler
configurations of GNAT and the GNU tools are certainly feasible in this
category. Someone out there may already have done this for your
prospective architecture. I've lost the original post, but if you're
still listening, what processors did you have in mind?  Would you
consider, let's say, a 680x0 or a 80X86?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "johnv@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------

Re: ada and robots

[dana]

In article <339974E0.335E@sprintmail.com>, johnvolan@sprintmail.com wrote:

> 
> Dana's points are well-taken, but let me steer the discussion slightly
> into a different avenue: If we're talking "hobbyist" category work, then
> what about GNAT?
> 
<snip>

> - GNAT looks much more feasible for processors in the 32-bit range, and
> as Dana points out, the price of these has been falling. Cross-compiler
> configurations of GNAT and the GNU tools are certainly feasible in this
> category. Someone out there may already have done this for your
> prospective architecture. I've lost the original post, but if you're
> still listening, what processors did you have in mind?  Would you
> consider, let's say, a 680x0 or a 80X86?


I just got my EE Times and with the usual product guide/ad section.  There
on the front page is what we've been looking for.  

--------------------------------------------------------------------------
The SMX/386/40 PC module from ZF Microsystems.  a complete 40MHz 386 pc in
a 2.2x3.0x0.45 module with 2M of dram, IDE drive controller, floppy
controller, 2 serial ports, parallel port, 256K of boot flash, BIOS,
(pretty much what i've paid $2000 for in 1989) single +5v supply, 750Ma
current!!  The module is $104 in 1,000's and on a pc104 card for $269.  
--------------------------------------------------------------------------
My guess is that it's a 386-EX-40 in a module w/$15 worth of DRAM and $5
worth of flash.  The price will fall to the floor over time.  Goodby 8051,
pic-16.  this little baby will (more or less) run the same binaries as
most every desktop machine on the planet.  This looks like the 32 bit
processor has finaly reached the mid price embedded market.  The fact that
you won't need e-prom burners, ICE's etc to use this dude might actually
make it a contender for hobyists.

I have no connectoin to ZF micro systems.  I've always thought that the
day would arrive when entire computer systems could be built into unitized
matchbox sized modules.