rdw2030@venus.tamu.edu (06/28/90)
C is really taking over! Everyone needs converters now! :-) In many cases, I'm afraid, it's probably easier and FAR MORE EFFICIENT to just write the program from scratch in C. As someone noted before, the code a converter produces is far from what a good programmer would produce. What's more, you end up with a LOT of uncommented code! AAAARRRRGGGGG!!!! Not only that, but if the program is relatively complex in its original language, it probably won't run perfectly after conversion, meaning some poor soul gets to go in and try to MAKE it work!! That's where the no-comments problem comes into play! I've never used a converter before, but I've heard about what they do. What kind of performance (or lack thereof) have the readers of this group seen? Mark C. Lowe - KB5III
wvenable@spam.ua.oz (Bill Venables) (07/07/90)
In article <55422@lanl.gov> rdw2030@venus.tamu.edu writes: >C is really taking over! Everyone needs converters now! &c &c Anyone used to the look and feel of C is going to find the prospect of working with large quantities of elderly Fortran code distasteful. The sort of things that are most off-putting are statement numbers, fixed card layout, (particularly the silent ignoring of anything past column 72), weird control structures, endemic goto-isms, exotic I/O, bulk use of upper case and the general all round anti-structured flavour. There is, however, a nice tool that does a good job of converting Fortran code to a form instantly recognizable, nicely indented and fully readable to any C programmer. 95% of the statement numbers are removed, for example. It's called struct(1), it's part of most BSD Unix releases, and it converts Fortran into Ratfor. It should be more widely known and used. However it is and old program, and is somewhat limited to fairly deadpan Fortran. If you are faced with converting middling amounts of Fortran to C, (for example one or two standard linear algebra or eigenvalue subroutines), you have three main choices: 1) Use a Fortran to C converter (and usually end up with very odd C code), 2) Go right back to the algorithm and hand code it in C from scratch, and 3) Convert the code to Ratfor using `struct', and then manually convert that code to graceful C. On occasion I have found 3) a useful alternative, particularly when the original Fortran code is good code, and contains no I/O (which is always going to be a problem.) There are still difficulties in converting Ratfor into idiomatic C, particularly if multiply subscripted arrays are involved, but they are an order of magniture less than trying to convert raw Fortran into C, either by hand or by converter. Does anyone know of an updated version of struct? Has anyone tackled the job of writing a Ratfor to C converter? (This job could almost be done in emacs using a few tricky macros.) -- Bill Venables, Dept. Statistics, | Email: wvenable@spam.ua.oz.au Univ. of Adelaide, South Australia. | Phone: +61 8 228 5412
steve@taumet.com (Stephen Clamage) (07/08/90)
In article <55422@lanl.gov> rdw2030@venus.tamu.edu (Mark C. Lowe) writes: >I've never used a converter before, but I've heard about what they do. What >kind of performance (or lack thereof) have the readers of this group seen? I've written converters and used commercial and PD converters. A converter should leave comments more or less intact, but deciding where to put comments is not trivial. If the new language is at the same or lower semantic level, the bulk of conversion can be pretty good if the converter author is competent. If the new language is at a higher level, the conversion is going to be of poor quality. (Imagine going from FORTRAN 66 to C, and not having loops or data structures in the original -- the result is going to be very poor C code.) No matter how good the translation, there will be substantial hand work to make the program look right. Apart from formatting and putting the comments in the right places, the coding style won't look right. One problem area is the run-time library. FORTRAN has functions which have no counterpart in C. So do BASIC and Pascal. More hand work here. When you have a substantial program (many of thousands of lines), a good translator to take care of 85% of the simple stuff is very cost-effective. Rewriting the program is not always feasible. -- Steve Clamage, TauMetric Corp, steve@taumet.com