ada to C++ translation

ada to C++ translation

[John Hayward]

Does anybody have information on Ada to C++ language translators?

Thanks!

Re: ada to C++ translation

[Ira D. Baxter]

We build custom translators based on our generalized compiler technology,
DMS.
See http://www.semdesigns.com/Products/DMS/Porting/Porting_files/frame.htm.

--
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
http://www.semdesigns.com


"John Hayward" <haywardjohn@hotmail.com> wrote in message
news:d4a6cd7e.0202281909.25488168@posting.google.com...
> Does anybody have information on Ada to C++ language translators?
>
> Thanks!

Re: ada to C++ translation

[Jeffrey Carter]

"Ira D. Baxter" wrote:
> 
> "John Hayward" <haywardjohn@hotmail.com> wrote in message
> news:d4a6cd7e.0202281909.25488168@posting.google.com...
> > Does anybody have information on Ada to C++ language translators?
> >
> We build custom translators based on our generalized compiler technology,
> DMS.
> See http://www.semdesigns.com/Products/DMS/Porting/Porting_files/frame.htm.

Very interesting. That link shows me a couple of blank frames. How does
your generalized compiler technology translate Ada tasks and protected
objects into C++?

-- 
Jeffrey Carter

Re: ada to C++ translation

[Tucker Taft]

John Hayward wrote:
> 
> Does anybody have information on Ada to C++ language translators?

Our AdaMagic Ada95 front end includes an option that can
translate Ada to optimized C/C++, preserving comments and
variable names.  It has been used for an 80KLOC conversion.

We generally make this capability available as a service
rather than as a product, but other approaches are negotiable.

> 
> Thanks!

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: ada to C++ translation

[Ira D. Baxter]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3C7FBEAE.B46E2EC5@boeing.com...
> "Ira D. Baxter" wrote:
> >
> > "John Hayward" <haywardjohn@hotmail.com> wrote in message
> > news:d4a6cd7e.0202281909.25488168@posting.google.com...
> > > Does anybody have information on Ada to C++ language translators?
> > >
> > We build custom translators based on our generalized compiler
technology,
> > DMS.
> > See
http://www.semdesigns.com/Products/DMS/Porting/Porting_files/frame.htm.
>
> Very interesting. That link shows me a couple of blank frames.

It does?  I just checked it with IE5.  No blank frames.
What browser are you using?

> How does your generalized compiler technology translate Ada tasks and
protected
> objects into C++?

We presently don't have an Ada to C++ translator.
Our tools are used to construct custom translators, and the claim
is that we can build such a translator.
For example, we have build JOVIAL to C translators.
And we have a nice start; our tools already can process Ada95
and C++, so the real task is to define the map between them.

How such things are defined are usually defined by customer dictate.
The value in our approach is that we *can* do that,
relatively economically.

The question for any Ada-to-C++ translation is,
what is the economic payoff in doing that?
If it exceeds significantly the cost of the custom translator,
then such a translator make sense.

The original poster asked what people know about such tools.

Re: ada to C++ translation

[Robert Dewar]

"Ira D. Baxter" <idbaxter@semdesigns.com> wrote in message news:<3c81060d$1@giga.realtime.net>...

> And we have a nice start; our tools already can process 
> Ada9 and C++,

But that's relatively straightforward. After all anyone
can process Ada 95 (I assume that Ada9 is a misprint)
using ASIS, and it is not clear what "processing C++"
means if you are generating C++ as the output.

> so the real task is to define the map between them.

That indeed is the (very difficult for Ada to C++) part.
A translation from Jovial to C is by comparison entirely
trivial, since the languages are both low level languages
with no major semantic problems in the translation that
I can see.

> How such things are defined are usually defined by 
> customer dictate

That's a very tall order for Ada to C++. For example,
in the case of object oriented stuff, the correspondences
are far from trivial, the same is true for generics and
templates.

Going back to the tool environment, it seems clear that
starting with ASIS is the best here, although your tools
may "process" Ada 95, it is very unlikely that they 
generate the full semantic information available from ASIS
and for sure it seems like you need this full information
for an automatic translation to C++.

What is certain is that, even with this starting point,
this translation is a major project.

What is not certain is that it is a practical project.

Of course one can translate Ada to C, just as one can
translate C++ to C (that is after all what C front does),
but most usually people who ask a question about Ada to
C++ translation have legacy Ada code that they want to
magically translate into high level maintainable C++.

I am dubious that this is possible at all, and even more
dubious that it ever makes sense to attempt it.

Re: ada to C++ translation

[Ira D. Baxter]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:<5ee5b646.0203021621.ce5a579@posting.google.com>...
> "Ira D. Baxter" <idbaxter@semdesigns.com> wrote in message
news:<3c81060d$1@giga.realtime.net>...
>
> > And we have a nice start; our tools already can process
> > Ada9 and C++,

>  (I assume that Ada9 is a misprint)
[Yes, fumble fingers happen, sorry.]

> But that's relatively straightforward. After all anyone
> can process Ada 95 using ASIS,
> and it is not clear what "processing C++"
> means if you are generating C++ as the output.

If you have a code generator that directly produces
fragments of C++ text, then "processing C++" is uninteresting.
It also makes composing generated fragments difficult,
because the composition has to be pure macro-like
substitution or text concatenation.  This
kind of approach can produce C Front like code,
but it is likely to be inefficient and hard to maintain.

Our tools manipulate trees, which allows them
to compose fragments and then carry out optimizations
on the result, because the tool understands the structure
(and to the extent one is willing to invest
effort) the semantics of such structure.
"Processing C++" means that our tools can
parse/compose/transform/prettyprint C++ code.

> > so the real task is to define the map between them.
>
> That indeed is the (very difficult for Ada to C++) part.
> A translation from Jovial to C is by comparison entirely
> trivial, since the languages are both low level languages
> with no major semantic problems in the translation that
> I can see.

Language translations are almost never trivial.
JOVIAL has all kinds of nasty stuff.   Data overlays.
Packed fields.  Macros. Exceptions(!).

> > How such things are defined are usually defined by
> > customer dictate
>
> That's a very tall order for Ada to C++. For example,
> in the case of object oriented stuff, the correspondences
> are far from trivial, the same is true for generics and
> templates.

I'll agree, that the Ada to C++ translation is probably
harder.

[Now that I understand that Averstar claims to have
such a tool, I offer them as an existence proof].

 [The point I had intended to make is that customers
often have lots of secondary issues about execution
environments, libraries, etc. that they want taken
into account for such a translation.  This
adds to the scale of the translator engineering.]

> Going back to the tool environment, it seems clear that
> starting with ASIS is the best here, although your tools
> may "process" Ada 95, it is very unlikely that they
> generate the full semantic information available from ASIS
> and for sure it seems like you need this full information
> for an automatic translation to C++.

ASIS certainly has a leg up in have the full semantic analysis
of Ada available to it.   We presently don't go so far
with *Ada*.   We do go that far with C and Java, so it isn't
a tool limitation, it is an engineering investment problem.
And yes, this is a significant investment, and would
probably count for half the effort in a translator.

OTOH, being able to "process" the resulting code
(by composition, optimization, etc.) is key, we
think, to produce a translated result that appears
clean.   ASIS offers nothing here.  One could argue
this, too, is just an engineering problem.

The difference is that DMS was designed as infrastructure
for this overall task.   I don't believe ASIS was.
This is not to denigrate ASIS; if you want analysis
in the Ada world, it looks like a very good tool.
If  you want more, it might not be the right tool.

> What is certain is that, even with this starting point,
> this translation is a major project.

Agreed.

> What is not certain is that it is a practical project.

> Of course one can translate Ada to C, just as one can
> translate C++ to C (that is after all what C front does),

This is pure code generation.  Smart folk don't look
at the result, they just compile and run it.

> but most usually people who ask a question about Ada to
> C++ translation have legacy Ada code that they want to
> magically translate into high level maintainable C++.

Agreed.

> I am dubious that this is possible at all, and even more
> dubious that it ever makes sense to attempt it.

We think if it is practical to produce such code,
our tools are well positioned to do this.
[And if Averstar already does this well,
the point is probably moot].
YMMV.

I'll be the *last* person to push somebody into such
a conversion.   If there's a more economical
(or more business-sensible) approach that leaves
them in Ada, that's the way they should go.
If such a conversion starts and the value isn't
really clear, it'll get killed in mid project and
that wastes everybody's time, including ours.
And I'll even agree that many starry-eyed
desires for conversions are probably not sensible.

That doesn't mean that conversions are always
inappropriate.   Rightly or wrongly, people
perceive that engineers with good Ada skills are
hard (and getting harder) to find, that tool
vendor support is fading, that end-customer
acceptance is weakening for those reasons.

Personally, I think this is a shame.  I'm actually
a closet Ada fan; it appears to have one of the
most rational designs of any of the languages I've
seen, and systems built in it appear to generally have
better quality.  (One might argue this
is caused by filtering out people who
won't read the LRM).

But I'm not the marketplace, and it doesn't
always do what we personally think is technically
rational.

If you remember BetaMax VCRs, they were technically
better than VHS.  But the only VCR survivors
made the arguably rational business decision to go with VHS.

This is not a recommendation on my part to switch to C++.
It is merely an observation that some businesses
likely will.

Ira D. Baxter, Ph.D. CTO Semantic Designs
512-250-1018 http://www.semdesigns.com

Re: ada to C++ translation

[Chad R. Meiners]

"Ira D. Baxter" <idbaxter@semdesigns.com> wrote in message
news:3c838b53@giga.realtime.net...
>
> If you remember BetaMax VCRs, they were technically
> better than VHS.  But the only VCR survivors
> made the arguably rational business decision to go with VHS.
>

Please search Google groups in comp.lang.ada for Dr. Dewar's argument why
the Beta vs. VHS analogy is not well formed.

-CRM

Re: ada to C++ translation

[Robert Dewar]

"Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<a60is1$21tb$1@msunews.cl.msu.edu>...

> Please search Google groups in comp.lang.ada for Dr.
> Dewar's argument why the Beta vs. VHS analogy is not well 
> formed.

To save people the trouble, the summary is as follows.

VHS dominated Beta because it was technically superior. In
what respect? In respect to the playing time you could get
on a tape. Yes, the image was not as good, but the market
place spoke loud and clear, playing time was more important than image
quality, and Sony failed to understand this.

You still see this today in the DVD market. Many DVD's are
over compressed, but people prefer to have hours and hours
of junk extras to having just the movie at the highest quality. The
few "superbit" DVD's that are available show
the difference in quality quite clearly (compare for example the
Superbit transfer of Air Force One to the
standard transfer). Many DVD's have significantly poorer
quality than the corresponding laser disks, at least partly because of
digital artifacts from excessive compression,
but the market place likes the long playing times.

(my own taste is to prefer laser disks still in many cases
to the corresponding DVD's, though there are exceptions,
and perhaps my observations are not really level playing
field, since I have an HLD-X9 laser player :-)

How's that for getting off the topic completely? [well
*someone* thought once again that beta vs VHS was a relevant analogy,
sigh]

Anyone interested in home theater is welcome to visit me
in NYC to see my setup here :-)

Re: ada to C++ translation

[Steffen Huber]

Robert Dewar wrote:
> 
> "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message > news:<a60is1$21tb$1@msunews.cl.msu.edu>...
> 
> > Please search Google groups in comp.lang.ada for Dr.
> > Dewar's argument why the Beta vs. VHS analogy is not well
> > formed.
> 
> To save people the trouble, the summary is as follows.
> 
> VHS dominated Beta because it was technically superior. In
> what respect? In respect to the playing time you could get
> on a tape. Yes, the image was not as good, but the market
> place spoke loud and clear, playing time was more important than image
> quality, and Sony failed to understand this.

This might explain the success of VHS when battling against Betamax,
but it does not explain why VHS won over Video2000 (I am not sure
if Video2000 was available outside Europe). Video2000 was able
to record 16 hours per tape (8 hours without switching sides),
tapes were cheaper than VHS ones and the quality was a lot better.

We Europeans usually use the VHS vs. Video2000 comparison when
trying to explain the success of Windows vs. the world ;-)

When we discuss the VHS vs. Video2000 vs. Betamax situation, usually
things like licencing costs for the system, availability of
"software" in stores and the fact that JVC gave VHS copying machines
virtually for free to video producers (especially the porn guys)
are cited as reasons for the VHS success.

[snip]

Steffen

-- 
steffen.huber@gmx.de               steffen@huber-net.de
GCC for RISC OS  - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/

Re: ada to C++ translation

[Kevin Cline]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0203021621.ce5a579@posting.google.com>...
> Of course one can translate Ada to C, just as one can
> translate C++ to C (that is after all what C front does),

That problem got a lot harder when exceptions
were introduced into C++.  C-front was abandoned
at that time.

Re: ada to C++ translation

[Robert A Duff]

kcline@optelnow.net (Kevin Cline) writes:

> That problem got a lot harder when exceptions
> were introduced into C++.  C-front was abandoned
> at that time.

It's not all that hard to translate exceptions into C using
setjmp/longjmp.  It's grossly inefficient, though.

- Bob

Re: ada to C++ translation

[John Tate]

> http://www.semdesigns.com/Products/DMS/Porting/Porting_files/frame.htm.
> 
>>Very interesting. That link shows me a couple of blank frames.
>>
> 
> It does?  I just checked it with IE5.  No blank frames.
> What browser are you using?

Obviosly the person who wrote the site is a microsoft junkie who needs
to make the shit thing work with Netscape & other browsers.
Becuase there is more to the world than just microsoft i use Linux and 
windowsand netscape is better than IE face it.
People who cant make HTML sites work as HTML not as what i refer as: 
MHTML - Not real HTML because HTML parsers cant read it only Internet 
Explorer. goto www.toastytech.com/evil

STOP USING MICROSOFT!!!
-- 
=========================
Messege sent by John Tate

Icq: 		131351395
Msn: 		goon_666@hotmail.com
Yahoo: 
	Bongrat_au@yahoo.com
Netscape 
GOON666A69

Re: ada to C++ translation

[Ted Dennison]

John Tate <tate0@bigpond.com> wrote in message news:<3C88FA56.9000502@bigpond.com>...
> > http://www.semdesigns.com/Products/DMS/Porting/Porting_files/frame.htm.
> > 
> >>Very interesting. That link shows me a couple of blank frames.
> >>
> > 
> > It does?  I just checked it with IE5.  No blank frames.
> > What browser are you using?
> 
> Obviosly the person who wrote the site is a microsoft junkie who needs
> to make the shit thing work with Netscape & other browsers.

It doesn't work w/ Mozilla either. 

Worse yet, it doesn't even come close to validating as HTML. In fact,
it hits the 35 error limit quite quickly. I do wish web page authors
would show a wee bit of professionalism and start validating their
sources before publishing them. I just don't understand how people in
good conscience can take other people's money to develop a website,
and give them something that isn't even real HTML.

Running a page through the WC3 validator (http://validator.w3.org/ )
takes hardly any time at all. Once you've done that, if there's some
display problem on some weird browser, then and only then can you
blame the browser and not your own lazy self.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: ada to C++ translation

[Ted Dennison]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0203080746.203cb871@posting.google.com>...
> sources before publishing them. I just don't understand how people in
> good conscience can take other people's money to develop a website,
> and give them something that isn't even real HTML.
> 
> Running a page through the WC3 validator (http://validator.w3.org/ )
> takes hardly any time at all. Once you've done that, if there's some
> display problem on some weird browser, then and only then can you
> blame the browser and not your own lazy self.


I should note that the 0.9.9 version of Mozilla's HTML editor not only
appears to make valid HTML, but it actually has a validate button that
will help you submit your work to the validator!

That's a significant improvement, considering it was a pervious
version of this very tool that produced results so crappy that it put
me off HTML editors entirely.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html