FOR_C

FC FAQs
FC Examples
FC Extensions
License-Single
License-Group

HOME

 

Cobalt Blue Logo
FOR_C FAQs
 

What's unique about FOR_C?

  • FOR_C was the first FORTRAN to C translator to generate C prototypes from the original FORTRAN, permitting FORTRAN argument checking, and determining which user function arguments could be passed by value (versus address).  This resulted in greatly simplified function call translations, which are much easier to maintain.
  • FOR_C was the first FORTRAN to C translator to pass intrinsic functions by value rather than address.  This results in faster code - and permits calls directly to the standard C library (rather than an intermediate function which, in turn, calls the C library function using the normal pass by value).  
  • Similarly, FOR_C was the first to translate statement functions using pass by value for scalar arguments, for simpler, easier to maintain code.
  • FOR_C was the first FORTRAN to C translator to generate optional translation to standard C fprintf() and fscanf() functions from F77 formatted WRITEs and READs. It was also the first to translate list directed WRITEs into fprintf()'s.  We also created the fscanunf() and fprtunf() functions to satisfy the translation of unformatted READs and WRITEs.  [These functions are not standard C, but fill a gap in the standard C library, i.e. they are the unformatted equivalents to fscanf() and fprintf()].  In general, FOR_C's I/O translations are the best available.  (NOTE: F77 I/O statements comprise roughly 20% of the F77 language, so a poor I/O translation guarantees a lot of C code must be rewritten!  We have heard from users of a competitor's product that I/O translations usually require the largest amount of rework after translation - or, put another way "they aren't worth the paper they're written on"!
  • Our DATA statement translations remain unique and uncopied, best representing the original FORTRAN programmers' intent.  Simple scalar and array initializations with varying constants are initialized with normal C static statements followed by the constants.  DATA statements involving implied DO loops become for-loops, with assigned initializations best representing the looping nature of the original F77.  Large arrays initialized with large repeat constants are translated using various forms of assigned initialization best suited to the problem at hand.
  • Our common translations to external C structures were also a first (an idea  suggested by a user)

How Complete is the Translation?

Very complete - and accurate!  The C code produced by FOR_C compiles with ANSI C without errors - excepting any literal lines used to pass unsupported proprietary FORTRAN statements through the translator untouched.  As far as accuracy goes, we translate, compile, link, and execute the GSA FORTRAN-77 compiler benchmarks, and pass over 99% without touching any of the generated C code (see Q2. below).  This is better than many FORTRAN compilers we've tested!

We have users who have successfully translated applications of over 1 million lines using FOR_C, with typical translation projects in the 50,000 to 100,000 line size.  We had one user who translated 1,121,000 lines of Sun FORTRAN  into C (the code was used for various plotting tasks) and had it running in 24 hours!   Another user translated over 1,500,000 lines (used for extensive graphics) and had it up and running in about 4 months.  It would take over 30 man-years to accomplish the same task by hand conversions (or rewrites)! 

You claim the C code is extremely readable.  Are there any exceptions to this?

Complex translations are very hard to maintain in C, and they cannot be improved upon due to language limitations in C.  The best translation for code with complex numbers is to C++.  In fact, C++ offers other advantages over C in certain areas and we feel C++ is the ultimate successor to FORTRAN.

Additionally, if your code contains very elaborate equivalences, you will get some very intricate C code.  Normal, simple equivalences should be straight-forward.
 

How does FOR_C handle "spaghetti" code with lots of GOTOs?

FOR_C will eliminate the label on an unreferenced do loop, but any other jumps to associated labels will be translated to comparable goto's in C.  The bottom line is that spaghetti FORTRAN will, unfortunately, result in spaghetti C - not a very natural result.

As a solution, we offer FOR_STRUCT  - a product which will restructure your spaghetti FORTRAN and produce clean, maintainable code.  This is a MUST for reusing and upgrading your old FORTRAN, either before translating it to C, or simply to make it more maintainable.   FOR_STRUCT  pays for itself with only a few thousand lines of code being restructured!
 

How does the speed of the translated C code compare with the original FORTRAN?

With most code, there isn't much difference.  Some programs run faster in C (usually due to faster C compilers), and some run faster in FORTRAN.  Integer arithmetic and native I/O is normally faster in C, whereas complex arithmetic is definitely faster in FORTRAN.  Double precision arithmetic is about the same in both languages.
 

Does FOR_C perform any optimizations?

FOR_C does a number of optimizations for code readability.  For example, the common translation is generated only once in a file as long as it remains unchanged in subsequent usage.  The same applies for parameters.  Our C code generation logic is very detailed and it produces very readable, clean C code, e.g. there are five (5) variations of the do loop translation.  Similarly, there are countless translations of the initialization and data statements.

FOR_C also offers options for more traditional optimizations.  These include optimizations to eliminate unused variable and function names, optimizations of assignments using the C +=, -=, x= and /= operators, for tighter code.  More elaborate and traditional optimizations, we feel, are best left to the compiler.  Most of our users get uncomfortable when their original code is overly rearranged.
 

Does FOR_C do any error-checking?

FOR_C issues error messages similar to those given by a compiler.  Additionally, FOR_C offers some basic static analysis of arguments (when prototypes are used) and commons.
  

Explain  your GSA Testing:

The GSA FORTRAN-77 compiler benchmarks are comprised of 3602 tests, spread over 200+ programs, and consist of over 110,000 lines of code - testing some of the most obscure constructs imaginable.

Of the 0.5% (or 20 tests) we missed on the GSA benchmarks, most are related to embedded spaces in keywords.  The others are miscellaneous.

Standard FORTRAN-77 is totally space INsensitive, allowing for embedded spaces and joined alphanumeric characters.  FOR_C requires that FORTRAN keywords be space sensitive - this permits better error checking and faster parsing.  Any keyword formed from a compound word (e.g. ENDIF) can be referenced as its compound form, or as the two separate words (i.e. END IF).  User names are space insensitive.   Requiring space sensitive keywords caused FOR_C to fail or parse such constructs as "R E A L" for the keyword REAL, consequently it missed 1/2% of the benchmarks.  All the occurrences were recorded as errors by its parser, so it is simple to correct the problem in practice (but improper to modify the benchmarks!).
 

Can I translate on a PC, then move the C code to another platform?  

Definitely - in fact, many of our users do just that!  The emphasis on ANSI C, plus the fact you get C source to the runtime library, result in highly portable C code.  You have complete control over where your program runs.  There aren't any extra charges, delays, or limitations every time you want to move your code to a new machine, and there aren't any royalties charged on the use of our runtime source in your executable C program. Portability is very high on our priority list!
 

What if my FORTRAN-77 was developed on a mainframe, or mini-computer and I'm bringing it down to the PC?

FOR_C has options to help you port code from 32 bit machines (mainframes and minis) to 16 bit machines (e.g. PC's), from 16 to 32 bit, and 32 to 32 bit. The default is 32 bit to 32 bit word size, since most FORTRAN applications will require a 32 bit environment (even on DOS)
 

Can FOR_C be customized?

Yes, by using preprocessing capabilities built into the translator.  FOR_C also supports a custom statement to add proprietary generic and specific intrinsic functions to the standard F77 intrinsic table, built in to FOR_C.

The FOR_C preprocessor is almost identical to that of C, with only minor differences to compensate for FORTRAN as the source language.  The preprocessor is used to change C keyword names used in the FORTRAN as identifiers, to avoid conflict in the generated C source.  It can also be used to turn unsupported proprietary FORTRAN statements into either comments or literal lines that pass through the translator untouched, thus allowing you to delay the changes until later.  The preprocessor can also be used to rename a user's FORTRAN library to a similar C library at translation time.  In general, anything that can be done with a C macro can be done with the FOR_C preprocessor - plus more!

If further customizations are needed, additional utilities like AWK (available with UNIX, or from MKS or Polytron on MS-DOS) can be used as a front-end to FOR_C to provide a proprietary FORTRAN to FORTRAN-77 capability.
 

What is the Runtime Library?

We emphasize standard C code and functions, whenever possible, in the translation process, but some FORTRAN statements have no equivalents in standard C (e.g., FORTRAN unformatted I/O).  These statements are translated to runtime library calls.  The runtime library provides the missing 'link' for the translated C code.

We have reduced the number of functions in our library by 50% since first releasing FOR_C, by introducing various optimizations and new translations which employ standard C code or functions.  Maximizing the use of standard C functions makes the code more familiar and easier to port to different compilers and platforms.

Our runtime library includes all the functions generated during the translation process, plus all standard FORTRAN-77 intrinsics which are not part of the standard C library. Several intrinsic extension functions are also included.  However, we don't include any functions which are part of third party or operating system libraries - you will need to resolve these separately.

DETAILS OF THE LIBRARY:

The runtime library consists of two conceptual parts:

1.  FORTRAN-77 intrinsics which may already exist in your code as calls, but are not part of the standard C library, and

2.  Functions that we inject into the C code to support the translation, when neither a standard C statement nor library function will do the job.  This category mainly consists of I/O (formatted, unformatted, and supporting routines), complex number expression support, and character expression support.

If we did not provide these functions, you would not be able to successfully build (i.e. link) the application in C.
 

Are there any circumstances where I don't need the runtime library?

Yes.  If you are translating a FORTRAN library that primarily does number crunching (e.g., matrix or numerical analysis), then there will be little, if any, dependence on FOR_C's runtime library
 

Do you charge royalties on the translated code?

The translated code is still your code, therefore Cobalt Blue does not claim any of it!  You may do with it as you like.
 

What exactly is a trial run?

During a trial run, all comments and spacing are deleted so that readability is severely impaired.  This does not affect the compilation process, but its use is recommended so that the effects of certain translation options can be assessed before committing to a final translation.

Trial runs also satisfy the need (very economically) of users who use FOR_C in place of a FORTRAN compiler, since this is a repeat use case, where the user doesn't care about the look of the resultant code.
 

What's the payback on FOR_C?

It takes just a few minutes to translate with FOR_C, compared with the days, weeks, or even years it would take to hand-translate the same code (assuming you use smart editors with macro capabilities, and you know what you're doing)!  
 

How is FOR_C being used by your customers?

Most of our customers are using FOR_C for one-time translations, and then shelving their FORTRAN-77 code, although some are using it to maintain both FORTRAN and C, spinning off a C version when needed.

Because FOR_C supports more VAX extensions than many FORTRAN compilers, it is also being used as a porting tool.  It converts proprietary, non-standard VAX FORTRAN into standard, portable C code - which can be moved to any computer with an ANSI C or System V compiler!
We have tried to cover most commonly asked questions in this FAQ sheet, but if you need more information, call us at (678) 521-7335, or E-Mail us at:  support@cobalt-blue.com .  (If you are a current user and need Tech Support, give your version number, specific details of problem and attach code sample, if appropriate.)