Converting Ada Tasks To VxWorks Tasks?

Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

We have a large multi-tasking system in Ada (83) that my employer wants
to convert to C++ running on VxWorks.

Since I designed all of the tasks in the system I've been tasked with the
task
of writing a white paper on how one would go about converting Ada tasks
into VxWorks tasks (apologies for the pitiful attempt at humor).

Things were going halfway decent until I realized that my approach
wasn't going to handle selects with guards, or conditional and timed entry
calls.

I'm sure I've read that there are implementations of Ada running on
VxWorks, so a mapping must exist.

Is anyone aware of any existing works that I could "borrow" from?

Thanks!
                Michael

Re: Converting Ada Tasks To VxWorks Tasks?

[Ted Dennison]

In article <1crJ4.142$d21.18564@elnws01>,
  "Michael Hartsough" <Michael-Hartsough@mediaone.net> wrote:
> We have a large multi-tasking system in Ada (83) that my employer
> wants to convert to C++ running on VxWorks.
>
> Things were going halfway decent until I realized that my approach
> wasn't going to handle selects with guards, or conditional and timed
> entry calls.
>
> I'm sure I've read that there are implementations of Ada running on
> VxWorks, so a mapping must exist.


Two or three. I believe Gnat, Green Hills AdaMulti, and ObjectAda all
exist for vxWorks.

Why don't you also include a cost comparison of converting to C++ on
vxWorks vs. converting to Ada95 on vxWorks? I suspect your manager will
be quite impressed at the difference. You can always write new code in
his pet language-o-the-day and link it in.

I can tell you from looking at the Windview logs that it looks like the
Green Hills compiler handles task synchronization by using vxWorks
semaphore objects. Perhaps that will help you look in the right
direction. If you want to exactly clone all of Ada's tasking semantics,
you'll have a big job ahead of you. For instance, I believe if you have
a selective accept with multiple open and waiting accept alternatives,
you have to *randomly* pick one to service.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Converting Ada Tasks To VxWorks Tasks?

[dale]

Ted Dennison wrote:

>  For instance, I believe if you have
> a selective accept with multiple open and waiting accept alternatives,
> you have to *randomly* pick one to service.


The accept that is chosen is non deterministic as far as the RM is 
concerned. This may translate into a deterministic choice by the
underlying scheduler.


Dale

Re: Converting Ada Tasks To VxWorks Tasks?

[Robert Dewar]

In article <dale-582DE5.10532114042000@news.rmit.edu.au>,
  dale <dale@cs.rmit.edu.au> wrote:
> Ted Dennison wrote:
>
> >  For instance, I believe if you have
> > a selective accept with multiple open and waiting accept
alternatives,
> > you have to *randomly* pick one to service.
>
> The accept that is chosen is non deterministic as far as the
RM is
> concerned. This may translate into a deterministic choice by
the
> underlying scheduler.
>
> Dale


In the core semantics of Ada 95, the choice of alternatives
is non-deterministic (which is totally different from random,
if you do not know the difference, put it down on the list
of useful things to learn, it is too much of a diversion to
this thread to discuss this difference here).

In the real-time annex semantics, provision is made for
removing ALL such non-determinism from the scheduling. So
the above reply by Dale is a little misleading





Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Converting Ada Tasks To VxWorks Tasks?

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

>...If you want to exactly clone all of Ada's tasking semantics,
> you'll have a big job ahead of you.

Probably tens of thousands of lines of code.

>... For instance, I believe if you have
> a selective accept with multiple open and waiting accept alternatives,
> you have to *randomly* pick one to service.

No, that's not quite right.  The choice is "arbitrary" by default, which
means that the Ada run-time system can always pick the first one.  It is
not (necessarily) random.  If you select the Priority_Queuing policy,
then it's more deterministic: it always picks the first one (see
D.4(14)).

- Bob

Re: Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccaeiwblzf.fsf@world.std.com...
>
> No, that's not quite right.  The choice is "arbitrary" by default, which
> means that the Ada run-time system can always pick the first one.  It is
> not (necessarily) random.  If you select the Priority_Queuing policy,
> then it's more deterministic: it always picks the first one (see
> D.4(14)).

The major problem I've got is that although there are several features
which get me nearly there, there's no feature that solves everything,
and I don't see a way of combining features to find a collective
solution.

There's a Select statement, but you can only use it with Pipes.
Pipes would be okay, but they run on top of VxWork message
queues and the messages aren't queued in priority order (okay,
you Do get a choice of two priorities. Normal and High, but I see
that as so restricted as to be useless). VxWorks implements
POSIX queues which have 32 priority levels, which would be
sufficient for my needs, but Pipes don't use them. So you can't
use the Select statement.

Semaphores have priority queues, but I haven't figured out a way
to implement a Select statement that'll use semaphores and be
able to handle a guarded accept without performing some sort
of polling.

Anyways, if anyone can provide me with some references to work that's
already been accomplished in this area I'd be mighty grateful.

Thanks,
                MJH

Re: Converting Ada Tasks To VxWorks Tasks?

[Tucker Taft]

Michael Hartsough wrote:
> ...
> 
> Semaphores have priority queues, but I haven't figured out a way
> to implement a Select statement that'll use semaphores and be
> able to handle a guarded accept without performing some sort
> of polling.
> 
> Anyways, if anyone can provide me with some references to work that's
> already been accomplished in this area I'd be mighty grateful.

Most Ada run-times are built on just a few low-level primitives of the
underlying system, in part because the required high-level Ada semantics
rarely match exactly the high-level primitives provided by a given
RTOS.  

As far as select statements, these require some relatively complex
data structures built up by the Ada run-time system, plus some
fairly low level signaling primitives (e.g. binary semaphores,
event flags, etc.) provided by the underlying RTOS.

Since the GNAT run-time is open source, you could conceivably
just go and read the implementation for select statements, etc.
and figure out what you need to do.  It is straightforward,
but far from trivial...

I might put in a plug for our Ada 95 compiler that uses optimized ANSI C
as its intermediate language.  This would allow you to
reuse the existing Ada code, and easily interface with
C/C++ code, and give your boss some readable C code to study
when he is curious what you are doing...
  
> 
> Thanks,
>                 MJH

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

"Tucker Taft" <stt@averstar.com> wrote in message
news:38F79478.5218D61@averstar.com...
>
> Most Ada run-times are built on just a few low-level primitives of the
> underlying system, in part because the required high-level Ada semantics
> rarely match exactly the high-level primitives provided by a given
> RTOS.

I knew it had to be possible since several compiler vendors provide
Ada compilers for VxWorks.

> As far as select statements, these require some relatively complex
> data structures built up by the Ada run-time system, plus some
> fairly low level signaling primitives (e.g. binary semaphores,
> event flags, etc.) provided by the underlying RTOS.

I was hoping it would be much simpler than this. I started freaking
out when my approach started looking like a semaphore tango, but
maybe it wasn't that bad after all!  "The client task first executes a
Give of the Service_Request semaphore, on which the server task has
executed a Take. When no clients are requesting service the server
task will be blocked. The client task will then execute a Take of the
Service_Granted semaphore. All client tasks will be blocked on this
semaphore until the server task unblocks on the Service_Request
semaphore and executes a Give on the Service_Granted semaphore.
This Give will unblock the highest-priority client task which will then
place the entry parameters into a static global structure.....".

> Since the GNAT run-time is open source, you could conceivably
> just go and read the implementation for select statements, etc.
> and figure out what you need to do.  It is straightforward,
> but far from trivial...

Great idea! I'll go look for it!

> I might put in a plug for our Ada 95 compiler that uses optimized ANSI C
> as its intermediate language.  This would allow you to
> reuse the existing Ada code, and easily interface with
> C/C++ code, and give your boss some readable C code to study
> when he is curious what you are doing...

I've already forwarded your message to my "work address" so I can
pass it around on Monday.

But, as I've already mentioned, "Ada" has become an evil word where
I work. A couple weeks ago I submitted a library purchase request
for an SEI paper on Ada (I think it was the "comparison of Ada to C"
paper) to my manager for her signature. She refused to sign it because
she has been forbidden from approving purchase of anything with the
word "Ada" in the title. And these things cost only about $7!! So they
won't be thrilled at the prospect of having to purchase an Ada 95
compiler.  ;^(

Thanks for the help!

        Michael

Re: Converting Ada Tasks To VxWorks Tasks?

[Jeff Carter]

I am a certifiable Ada expert (just ask my psychiatrist), and you may
tell your manager that I said that what he wants you to do is
impossible. Or at least it will take a Long Time and cost a Lot of
Money. You may also tell him that I could convert the code from Ada 83
to Ada in 1.5 days, since it is unlikely to require much more than a
recompilation, for only half of what the C++ conversion will actually
cost. He can keep a quarter of the difference for himself, lay off all
the C++ people, and get a big bonus for saving money.
-- 
Jeff Carter
"I waggle my private parts at your aunties."
Monty Python & the Holy Grail

Re: Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

"Jeff Carter" <jrcarter@acm.org> wrote in message
news:38F6623B.C365A224@acm.org...
> I am a certifiable Ada expert (just ask my psychiatrist), and you may
> tell your manager that I said that what he wants you to do is
> impossible. Or at least it will take a Long Time and cost a Lot of
> Money. You may also tell him that I could convert the code from Ada 83
> to Ada in 1.5 days, since it is unlikely to require much more than a
> recompilation, for only half of what the C++ conversion will actually
> cost. He can keep a quarter of the difference for himself, lay off all
> the C++ people, and get a big bonus for saving money.

Yeah, well.....

The moment the "mandate" was lifted, my Director Of Software
Engineering, who knows only the C programming language, announced
that "we" were a C shop. He's tired of trying to hire Ada-knowledgeable
developers, and tired of talking with those of us who know Ada. If you
know something he doesn't you're a threat to him.

I've been vilified by the powers-that-be for making this particular
program multi-tasking. In "our shop" the only way to implement
a real-time system is by employing a cyclic-executive.

Anyways, he has mandated that all Ada code shall be converted to
either C or C++. Ada compilers are too expensive. Ada developers
are too expensive to find and retain.

Forgive me for blowing off some steam. I spent 12 years being a
student of Ada, and now I'm being "retrained" to be a good little
C++ developer. My career, as I knew it, has been destroyed by this guy.

Later,
                MJH

Re: Converting Ada Tasks To VxWorks Tasks?

[Ted Dennison]

In article <r9CJ4.203$d21.25012@elnws01>,
  "Michael Hartsough" <Michael-Hartsough@mediaone.net> wrote:

> I've been vilified by the powers-that-be for making this particular
> program multi-tasking. In "our shop" the only way to implement a
> real-time system is by employing a cyclic-executive.

I've found a lot of places that do real-time work are conservative in
the extreme about this kind of thing. I think a large part of the reason
is that the job tends to require a lot of domain-specific knowledge that
has nothing to do with software engineering (eg: Engines, Avionics).
People who have that knowledge aren't nessecarily good s/w engnieers
(some are). But if they have one way of scheduling that's always worked
in the past and they know how to deal with, their goal in life is to
plunk down systems as close to that as possible from now on.

I discovered this myself the hard way when I tried creating a new
scheduler for a simulator. My first cut with everyone doing "delay
until" and no central scheduler, no-one would accept. The problem was it
did not rigidly constrain the order that tasks at the same priority ran.
I thought of that as an advantage, because you could plunk in extra
processors transparently to boost performance. But the domain engineers
always wrote their code assuming that model X ran to completion just in
front of them, and model Y will run to completion just after them. They
don't have to worry about synchornization with higher priority tasks
because they copy all the data they need from them into locals up front,
theoreticly before that higher-priority task has a chance to start
another iteration. They don't know any other way to write it, and
talking about other ways just scares them.

> Forgive me for blowing off some steam. I spent 12 years being a
> student of Ada, and now I'm being "retrained" to be a good little
> C++ developer. My career, as I knew it, has been destroyed by this

I myself spent 11 years at GE/Martin Marietta/Lockheed Martin. Believe
me, 11 years is a long time at a single company these days. C++ isn't
nessecarily a bad skill to learn at your company's expense. But if some
idiot over your head decides to take you up as their pet punching bag,
that's a really bad scene, and you can't do a damn thing about it (I've
been there too). They'll eventually reap what they sow, but that will
only be a small satisfaction to everyone else working there. As you
touched on before, Ada developers are in demand. Sometimes its time to
fish, and sometimes its time to cut bait...

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Converting Ada Tasks To VxWorks Tasks?

[Marin D. Condic]

Ted Dennison wrote:
> I've found a lot of places that do real-time work are conservative in
> the extreme about this kind of thing. I think a large part of the reason

While I agree with your points, I'd observe that probably the biggest
reason for sticking to something like that is risk mitigation. These
types of projects tend to be so expensive, time consuming and risky
enough for other reasons that nobody wants to get to just in front of
the production delivery and discover that the scheduler isn't going to
handle the job & all the code needs to be redone. (Especially if your
scheduler is non-deterministic, you can discover major fundamental flaws
as you bring in the very last pieces and it starts to fall apart.) I
succeeded in using a tasking scheduler on a rocket project and it did
present a change in mentality for the engine experts, but it did end up
working very well. Still, it was a *hard* sell because of the risk.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Converting Ada Tasks To VxWorks Tasks?

[Stanley R. Allen]

Michael Hartsough wrote:
> 
> The moment the "mandate" was lifted, my Director Of Software
> Engineering, who knows only the C programming language, announced
> that "we" were a C shop.
> 
> Anyways, he has mandated that all Ada code shall be converted to
> either C or C++. Ada compilers are too expensive. Ada developers
> are too expensive to find and retain.

I recommend making yourself hard to retain.  Ada developers are
in demand all over.  If they want to convert Ada to C, they need
people like you.  Tell them to forget it -- that you'll go elsewhere.

> 
> Forgive me for blowing off some steam. I spent 12 years being a
> student of Ada, and now I'm being "retrained" to be a good little
> C++ developer. My career, as I knew it, has been destroyed by this guy.
> 

Sad.

-- 
Stanley Allen
mailto:Stanley_R_Allen-NR@raytheon.com

Re: Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

"Stanley R. Allen" <Stanley_R_Allen-NR@raytheon.com> wrote in message
news:38F79EA3.84D28C46@raytheon.com...
> Michael Hartsough wrote:
>
> I recommend making yourself hard to retain.  Ada developers are
> in demand all over.

Unfortunately, to continue to work in Ada I would have to relocate.
Which is fine with me. But whenever I suggest to the "Mrs". that I could
get a better job in San Diego, or Seattle, or Rhode Island, or
Wherever, her response is always the same. "Good-Bye".
So basically, I'm stuck here.

>  If they want to convert Ada to C, they need
> people like you.  Tell them to forget it -- that you'll go elsewhere.

Won't work. Official policy is that nobody's indispensible. Especially
an Ada & Multitasking Advocate.  ;^)

Later,
            Michael

Re: Converting Ada Tasks To VxWorks Tasks?

[Robert Dewar]

In article <xEZJ4.334$d21.35336@elnws01>,
  "Michael Hartsough" <Michael-Hartsough@mediaone.net> wrote:
h
> Won't work. Official policy is that nobody's indispensible.
> especially an Ada & Multitasking Advocate.  ;^)

A bit off topic, but I really feel like making a comment on
this point. I agree that any company should have an official
policy that no one is indispensable, and should orient the
structure of development according to this point. After all
if an indispensable person is in a fatal accident, the company
can be very seriously impacted.

This is one of the reasons at Ada Core Technologies that I have
very strongly insisted on avoiding a situation where only one
person knows some code, and no one else can touch it. There
are two approaches that help:

  1. Avoid the use of author's names on units, or anything else
     that encourages the notion of ownership. Some formal
     configuration management procedures actually encourage
     or even insist on the idea that only one person can
     control changes to a unit, but I think that's a very
     bad idea.

  2. Insist on a highly uniform coding style, so that anyone
     feels comfortable with anyone else's code.

You know you are beginning to succeed here when A writes
some chunk of code, or perhaps a whole unit, and B fixes
a bug in it, and A's reaction is "great, that's one bug
I don't have to fix", instead of "Hey! What's B doing
mucking in *my* code?" I have been in far too many situations
at other companies where the second reaction is typical, and
where individuals have idiosyncratic coding styles that tend
to discourage the situation in the first place.

That being said, I find it extraordinary, and extremely
misguided that for many large companies, the policy of
avoiding indispensibility gets transmogrified to a viewpoint
that everyone is interchangable, and that, for example, if
you want to cut your work force, it doesn't matter who goes.

The fact remains that productivities vary hugely in our field,
and management failing to note this fact when they decide who
to retain is a very serious problem in companies that make
this fundamental mistake.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Converting Ada Tasks To VxWorks Tasks?

[Jeff Carter]

Robert Dewar wrote:
[Large discussion of excellent ACT management policies deleted]
> 
> The fact remains that productivities vary hugely in our field,
> and management failing to note this fact when they decide who
> to retain is a very serious problem in companies that make
> this fundamental mistake.

Everything that Dewar has posted here over time about ACT policies
certainly make ACT seem an attractive place for a S/W engineer to work.
Too bad I have neither compiler-development experience nor a desire to
live in NYC :)

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Re: Converting Ada Tasks To VxWorks Tasks?

[Michael Hartsough]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:8dc9t9$lij$1@nnrp1.deja.com...
> In article <xEZJ4.334$d21.35336@elnws01>,
>   "Michael Hartsough" <Michael-Hartsough@mediaone.net> wrote:
> h
> > Won't work. Official policy is that nobody's indispensible.
> > especially an Ada & Multitasking Advocate.  ;^)
>
> A bit off topic, but I really feel like making a comment on
> this point. I agree that any company should have an official
> policy that no one is indispensable, and should orient the
> structure of development according to this point. After all
> if an indispensable person is in a fatal accident, the company
> can be very seriously impacted.

To digress even further....

I believe that the reason my employer has this policy is to
prevent people from "extorting" them with job offers from other
places in attempts to get a counter offer to retain them.

They fear that if they try to retain someone by making a
counter offer it'll start an avalanche of people coming in with
job offers.

We have a large number of people who are single-points
of critical knowledge whose loss would be extremely costly.
But our management has such an intense focus on the near-term
bottom line that they would never add people to a project for the
sole purpose of spreading the knowledge. This is also the reason
for dropping Ada altogether and switching to C. "Ada compilers
are too expensive" (etc., we've heard it all before).

Re: Converting Ada Tasks To VxWorks Tasks?

[Jeff Carter]

Michael Hartsough wrote:
> that "we" were a C shop. He's tired of trying to hire Ada-knowledgeable
> developers, and tired of talking with those of us who know Ada. If you
> know something he doesn't you're a threat to him.
> 
> I've been vilified by the powers-that-be for making this particular
> program multi-tasking. In "our shop" the only way to implement
> a real-time system is by employing a cyclic-executive.
> 
> Anyways, he has mandated that all Ada code shall be converted to
> either C or C++. Ada compilers are too expensive. Ada developers
> are too expensive to find and retain.

So we have a manager making indefensible technical decisions, refusing
to listen to his technical people, and abusing his power because his
technical people managed to get something done well despite him. I
suggest you hit him back where it counts: Take an Ada job elsewhere. He
won't have anyone to translate his working Ada into non-working C++, and
no one to maintain it if he decides to keep it. Sooner or later the
consequences will affect his career; if not, you certainly shouldn't
want to be working there.

> 
> Forgive me for blowing off some steam.

No problem.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail