Re: Ada vs C++ vs Java

[Marin David Condic <condicma@bogon.pwfl.com>]

Ken Keys wrote:
> 
> Marin David Condic wrote:
> 
> > Not entirely accurate. Ada has the Task construct which allows parallel
> > programming without dependence on the specific OS. Typical
> > implementations on Unix and WinNT platforms will be via system calls.
> > However, since Ada was originally targeted for embedded systems, a
> > number of implementations go directly to the bare hardware and the
> > implementation's runtime support has to provide the primitives for task
> > scheduling, etc.
> 
> I suppose this is terribly off-topic discussing technical details in the
> middle of a flame war but...

But I was beginning to enjoy the flame war! ;-) I seriously believe that
most of the posts of the form "I hear that language X sucks..." or
"Which language is better: X or Y?" are really experiments by doctoral
students studying abnormal psychology. That, or they are started by
someone's artificial intelligence experiment gone haywire. :-)

> 
> Have you (or do you have first hand knowledge of anyone who has) ever
> used an Ada Rendezvous in an RTOS environment, such as, say, Vxworks? Or
> do you, like everyone I have ever met, use the OS services (semaphores
> etc.) directly?

Well, that depends on what y'all mean by "an RTOS environment". I built
a rocket engine control based on a Mil-Std-1750a microprocessor which
had 7 threads of control, 5 of which were tasks. We used Ada entries to
initiate aperiodic and periodic tasks, but they were just simple
entries, so the rendesvous was the simplest form and not very expensive.
The higher speed tasks (1ms, 5ms) had some data sharing or
synchronization issues which would have been well served by parameters &
the handshaking possible with the rendesvous, but the time was too
costly for the poor little 1750a. ****VERY IMPORTANT NOTE!!!!**** Before
someone runs off screaming about how this "proves" that Ada sucks, let
me state this: We were using ****ADA83!!!**** with the XD-Ada compiler
and did not have access to the more efficient constructs of Ada95
(protected types, etc.). So now the situation is a bit different -
although I know of no Ada95/1750a compiler and if one exists I have not
had a chance to see its code generation. (XD-Ada was pretty good for the
type of code we do.)

So XD-Ada provided its own built-in RTOS which is pretty common for
those of us in the bare machine business. A close comparison would be
using something like RTEMS with the GNAT compiler, but I've never done
any real time work with this setup. I have *never* used an RTOS of the
kind that most "real time" programmers are used to (versions of MS-DOS,
etc.) I have no objections to these - they just never seem to fit what
we do. Basically, we start with the Ada support and build up a real time
executive on top of that which allows our logic designers to schedule
their workload and have all their I/O handled. This is not the
environment most people are familiar with WRT real time.

Other controls we have done have had faster processors but used fewer
tasks, mostly because they were started a very long time ago before Ada
tasking had been reasonably well understood and optimized. We don't have
any problems doing tasks, etc. in Ada mostly because we were willing to
simply bite the bullet and learn how to use Ada effectively. Most of the
folks in our little shop here have grown quite expert in it and have
learned to love it over the years.

> 
> > Tasks in Ada provide parallelism in a machine-independent and
> > invisible-to-the-programmer manner. I do not know of a similar mechanism
> > in either C++ or Java. Maybe it is there. Maybe not. You'd need someone
> > else to fill you in on that.
> 
> Java has threads. In C++ it is more of a library issue. The C++ standard
> doesn't address it but Posix does. The RTOS probably includes a Posix
> library and if it doesn't, it probably doesn't support Ada either.

Sorry. I don't know much of anything about "Posix" except that it is
generally associated with Unix. We're down at the bare metal with hard
real time constraints so we don't have the luxury of a "real" operating
system. I hear that most of the Ada implementations that ride on top of
something like Unix will use as their underlying implementation of
tasking, Posix calls or similar. Still, this supports the point that the
language hides all of this from you and does it in a portable manner.

> 
> You need to be concerned with reentrancy and synchronization issues when
> you choose a C++  STL library, especially if you plan to use iostreams
> or other such goodies.
> 
> KLK

Ada subprograms are naturally reentrant (except of course when the
programmer does stuff like accessing global memory without appropriate
cautions.) and there are mechanisms for handling synchronization, so I
kind of enjoy not having to worry so much about it. However one of
Ada95's claim to fame is as the "glue" language for interfacing to
libraries, etc. in other languages. (I've done some of this with
Win32api calls, but not enough to consider myself an expert.) Obviously,
when doing this it is wise to know about the calling conventions, etc.
of the other language lest you create havoc with reentrancy from
multiple tasks.

I understand that CLAW - an interface to Win32api built by RR Software -
is supposed to wrap the Win32api calls up in appropriate Ada constructs
to make them tasking-safe. Something like this might be of value to more
than just Ada programmers.

MDC

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***

    "Nobody shot me."

        --  Last words of Frank Gusenberg when asked by police who
            shot him fourteen times with a machine gun in the Saint
            Valentine's Day Massacre.