From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,c0f035b936128b6c X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,c0f035b936128b6c X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Ada95 to ANSI_C converter Date: 1997/04/03 Message-ID: #1/1 X-Deja-AN: 230385760 Distribution: world References: <5hbrah$ctt$1@gail.ripco.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada,comp.lang.c Date: 1997-04-03T00:00:00+00:00 List-Id: In article <5hrh21$2k$1@gail.ripco.com> xanadu@ripco.com (Jennifer E. Lee) writes: > Philip Johnson 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