Re: Looking for FORTRAN to ADA compiler

Re: Looking for FORTRAN to ADA compiler

[Robert I. Eachus]

In article <1993Sep7.082700.4210@hsacsd.signaal.nl> Gerben Blom writes:

  > Does anybody know where to find a FORTRAN to ADA translator? We
  > will not use this for porting program structures as the
  > performance will probably be insufficient. It would help us a lot
  > in porting the large pieces of math calculations. Our goal is to
  > port a aircraft tracker written in FORTRAN to ADA, such that it
  > can be used for further development.

    First, there are services which will do this sort of translation,
as well as some tools.  However, when I have needed to do this sort of
"dusty deck" reclamation in the past, an editor script written in a
couple of hours for that particular source file got past the syntax
stage quickly.  You are going to need  a good elementary functions
package, but that is no longer much of a problem and many compilers
come with an implementation of the standard package.  (But watch it,
you want one that can be used it real time.)

  > We expect that the program structures will therefore have to be
  > changed considerably. The calculation algorithms will however
  > remain unchanged.

    Now for the good and bad news.  When you are finished, the code
will be better understood and more accurate than the original.  But,
from experience, you will spend a lot of effort finding bugs which
never showed up in the FORTRAN and proving that the final program
works better than the original.

     In the hope that I don't get flamed by know-nothings again, let
me stick in a few words here about what aircraft trackers are, and how
they are often written in FORTRAN.  A tracker takes data with lots of
ambiguity, errors, and inaccuracies (usually from one or more radars)
and tries to find and maintain in real time tracks of actual aircraft,
while ingnoring the noise and clutter.

     Since almost all FORTRAN implementations ignore overflow, a quick
and dirty way of handling out of range solutions is to leave the
"junk" data points in the data set and allowing later filters to
discard them.  Often this is exactly what happens to them, but
sometimes they are added to real tracks and perturb the solution, and
sometimes they create ghosts.  It would be nice to be able to say that
you can just turn checking off, but 1) that won't always help, 2)
turning off constraint checking to ignore known real errors is hard to
justify to anyone, and 3) it makes your program formally erroneous,
even if it does duplicate the FORTRAN behavior.

  > If such a translator is known, how is the performance in terms of
  > readability and efficiency?

    From experience, in some cases with aircraft trackers, the
translated code will be significantly easier to read. (Neat trick I
almost forgot translate "GOTO" into "end loop;" while tacking a loop
on the end of the named line.  It will almost always be correct and
when it isn't the compiler will usuallly complain.)  When you have
dealt with any overflow issues, expect the tracker to be about as
efficient assuming you have a elementary functions package which uses
the built-in hardware support.  If you have to spend a day or two
writing code inserts, it is worth it, but the performance you get may
be significantly less than a compiler integerated solution.

    Hope this helps.  I could add some horror stories about the bugs
uncovered in real trackers from doing just this, but I'll protect the
innocent.  (They really are innocent, the domain has just changed.
The requirements used to be 95% or whatever accuracy and runs fast
enough on the best machine of the day.  The requirements now are best
obtainable accuracy while keeping the computer hardware cost
reasonable.)


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...