Re: Ada to C/C++ translator needed

[wardi@rsd.bel.alcatel.be (Ian Ward)]

In article 87ee6fce@timpent.a-sis.com, "Tim Behrendsen" <tim@a-sis.com> () writes:
>
>Well, now you throw in new information that the problem in question
>was not able to be optimized due to constraints of the C language.
>Of course, this is still not relevent to a large project that
>presumably the original poster has.
>

Can I ask, are you agreeing with Richard here that, because of the
flexibility of "C"'s semantics, "C" compilers have a more difficult
optimisation task. (Or are you disagreeing.)

>> >The real question that you refuse to come to terms with is, what
>> >is the average case over a large set of compilers over a large set
>> >of non-trivial programs over a large set of problem types?  And
>> >this is a very difficult question to answer.
>> 

This is very difficult, noone I know has ever done this experiment.
I guess this is because it involves spending a lot of money.

>
>No, if *you* have.  Since you haven't brought up any large-scale
>comparisons, I have to conclude that you haven't done any.  If
>there are any large-scale project comparisons, they may be valid.
>

It is very difficult to do large scale comparisons, there are only
two of which I know. The first is the well documented case by
? Dr. Stephen Ziegler ? (apologies if the name is incorrect.)

The second is the Boeing 777 flight software, where three separate
projects (which was a really good idea,) were started to implement
the software, one in "C", one in PL1, and one in Ada. The problem
with comparing these languages in this situation was that a. Ada 
was designed for writing big, and reliable, and embedded systems.
Therefore it is unlikely that "C" was ever going to be at the 
same stage of development to make sensible comparions. (In fact,
that is exactly what happened, Byte described the projects of having
"nuisance disconnects" which was the politically sensitive way of
describing something else.) The end result was that "C" was being
used for something it was not designed for, and understandably it
was coping no better than it could have reasonably been expected
to have. Thus it was canned, as was the PL1. (This is my
interpretation of the printed word.)

>
>> Now _there_ is a non-sequitur, if ever there was one.  Can it be that
>> you are totally unaware of the work that has been done on link-time
>> optimisation of OOP programs to reduce the cost of dispatching?  (Not
>> only does this often eliminate dispatching, but that then enables
>> inlining, which permits more optimisations.)  As for the costs of
>> dynamic memory allocation, that can be extremely cheap, so why do
>> you think it might not be?  Are you unaware of the work on region-
>> based analysis?
>
>You live in the ivory tower; I live in the real world.  You may want
>to come out and get some fresh air once in a while.  If technology
>comes along such that these problems get solved, then I will
>embrace it.  Until then, why destroy my products in the name of
>"progress"?
>

It am sure that if (at least) GNU Ada decides that a dispatch can
be worked out at compile time, as it often can, then more likely than
not, it will do a direct call instead. This one optimisation I 
already know about, and I don't really know anything about the subject.
So I have to go with the ivory tower here. Compilers (all compilers)
really have come on, there are few low-level programmers that can
now keep up with them (even given the five or six hundred thousand
million times slower they are at writing assembler.)


>
>-- Tim Behrendsen (tim@a-sis.com)


Best regards,
Ian.
---
Ian Ward's opinions only : wardi@rsd.bel.alcatel.be