Re: Ada95 to ANSI_C converter

[jsa@alexandria (Jon S Anthony)]

In article <5hrh21$2k$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes:

> Philip Johnson  <philipj@hiwaay.net> wrote:
> >Jennifer,
> >
> >Why not write the application in Ada95 and use the Language interface
> >to "talk" to the HP Broadband system.  I am using a similar approach
> >to a data acquisition system now.  I wrote a simple interface package
> >to converse with the DAS driver dlls and it seems to be working fine.  
> >This was a proof of concept activity that convinced the customer that
> >Ada95 was a good choice.  I am now into the main project.
...[snip]...
> Thank you, but how?
> The HP Broadband Systems (HPBS) only recognizes ANSI C and TTCN 
> (Tree & Tabular Combined Notation) object codes.
> Our clients want us to integrate their Ada95 OO code with our C codes 
> which is almost impossible IMHO because C is not an OO language.
> How do we convert Ada's _package_, TEXT_IO, .... to HP's C function?
> The HPBS is a validation device for us to emulate our clients'
> SDH/SONNET/ATM networks.

I'm not Phil, but I am now getting the drift of what you are up
against.  Let me recap to see if at least the problem is now "clear":

  1. HPBS apparently only has a C compiler targetting it.

  2. There is (apparently) no way to communicate with the HPBS from
     another subsystem (which could have a board or some such which
     does have something more than a C compiler - in particular an
     Ada95 compiler.)

  3. Whatever it is that needs to be accomplished, the end result must
     _run_ on the HPBS (probably because of 2 or 2 plus some other
     reasons).

It sounds as if 1. is definitely true at the moment.  Is 2 really
true?  I find this somewhat hard to believe (as a variety of control
systems that I am aware of support this sort of thing).  If 2. really
is true then 3. would seem to follow automatically.

Now, if 2. is true (and thus 3), Ada.Interfaces is not going to help
you and Phil's suggestion is, unfortunately, not viable.

If 2. is _not_ true, then the "other subsystem which can communicate
to the HPBS" must have a library supplied for it which allows this
communication (this is standard for the sort of control systems I
mentioned above).  Presumably

a) this library's source would be in C, as you folks would be the ones
supplying it for your product!

b) your customer's Ada95 code is running on this thing (which implies
that it _does_ have an Ada95 compiler for it) as why else would they
believe that they could even use your product.

If a) and b) are true, then you are in luck and Phil's suggestion will
work like a charm.  Just use Ada.Interfaces to write an abstracted
interface to your library.  There is no problem in having OO Ada95
call out to your non-OO C.  Works fine.

Going back to the case of 2. being true (and thus a) and b) are
irrelevant), then we come to the following sort of possibilities:

  I.  Get some Ada95 to C compiler whose output will compile under the
      C compiler you have for the HPBS.  Maybe ICC's will work.

  II. Get someone (Aonix or ACT) to provide an Ada95 cross compiler to
      the HPBS (effectively giving the HPBS an Ada95 compiler).

The other possibility (which you mention) of recoding the Ada95 into C
is, IMO, much more expensive than either I or II and _far_ more risky.

Am I now correctly understanding the situation???

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