I'm trying to convert a Fortan77 program to C#. I have a subroutine with about 650 lines of code and horrific GOTO statements all over the place. I'm having a lot of trouble even starting to visualise the flow of the subroutine to figure out what it does.
Is there anybody with experience in this sort of thing who could give me any advice on how to get an overview of this subroutine? Are there some tools available to speed up or facilitate this type of conversion?
In my experience, a good way to go about this is to create a flow-chart of the Fortran code. Try to separate out the targets of the GOTO statements into separate blocks, and use the diagram to try to understand the code on a high level.
See if you can logically replace the GOTOs with loops or function calls; if the resulting diagram is in the form of a tree-structure, it is relatively easy to convert to C# without resorting to GOTOs. In the end though, you will need to understand the code intimately to be able to maintain and use the result with confidence.
goto is an extremely useful thing if applied wisely. You would not go implementing an efficient, large state automaton without a goto. You'll certainly need them in your generated code as well.
In addition to what Daniel B wrote above, I would say the following:
First, get your Fortran code to work with Fortran for DotNet. Not if you "can't get anywhere with the reprogramming", but before you attempt any reprogramming. It will be a small step, but in the right direction.
Then, write a test suite in C# which feeds the Fortran code with whatever input it was made to munch on, and stores the output. Run the test suite once, and save the output. Then, extend the test suite to test the produced output against the saved output. Assuming that the Fortran code always produces the same output when fed the same input, the test should of course succeed.
Then, while you are rewriting the code in C#, you will be running your code under the test suite, and it will be telling you whether your code is working properly or not, meaning, whether it is producing the exact same output as the Fortran code given the same input. Without it, you will be lost.
I do not agree with @SK-logic, you should NOT have to use any gotos at all in your C# code.
(But hopefully once you have made the Fortran code work under DotNet you will see no reason to continue wasting your time converting a piece of spaghetti code to C#.)
goto statemens can also make you code very hard to comprehend in some cases (and a state machine is the most important example of such a case). I just can't stand this stupid goto-bashing religion - people keep repeating the same meaningless BS without ever trying to understand the reason why goto is considered harmful.
Your task is tricky. You really need to know Fortran well. You have to be careful about how similar/different Fortran does calculations and what rules of truncation and rounding apply. Also, you need to be careful about the primitive types meaning in C# and Fortran.
Another approach from what has been suggestion (not necessarily a better one, it is just another one):
A - Consider re-writing the code in C# based on the business knowledge and the function, use the Fortran code just as a reference
B -Consider using a commercial tool that does the conversion job - Example: DataTek
If the routine represents a standard function or a function that you can buy a ready made dll for (such as numerical integration), use the standard function or the commercial product instead of manual translation, and your problem is solved.
If the above does not cut it, answer this question:
Do I need to optimize the code or just make it run. In other words, what is the business value of spending 500 hours to make the code better?
if there is no value in optimization, translate the code line by line and you are done.
If this is still not good, then:
0-Convert the Fortran code line by line into C# (or use Fortan CLR)
1-Do a quick test make sure it runs
2-Use a re-factoring (commercial tools are available) to help you write the code in a more optimized fashion.
Good luck.
A simple way of recoding stuff with lots of gotos is to draw a flowchart and pull the string straight. Sometimes, F77 programs are just old F66 programs or even worse FII programs. F66 did not have an if-then-else construct so gotos were necessary. All you need to do is invert the condition to get an if-then.
F66 did not have a do-while either but F77 does. It depends on whether the coder was a convert from F66 to F77 (like many today are C to C++ or C++ to C#) where they are using F77 like F66. If you can spot the patterns, in the coding, it is far easier to convert.
Before you get started, make a test suite to test the existing code. Be very thorough as this will help shed light on the behavior. You can then use this suite to gauge tne effectiveness of your conversion.
Beyond that, be methodical, don't rush, and use lots of paper to trace out the functionality.
Here is the way I actually went about translating the code into C#. Since .NET supports goto statements I first took the entire Fortran code and pasted it as is into a new method, well, as many methods as there were Fortran routines and subroutines.
The compiler came up with a million errors, mostly about undeclared variables and incorrect block statement formatting, which I cleared up one by one. I also had to rewrite some of the Fortran-specific code, like I/O statements and stuff like that. When that was done I had an exact replica of the original code.
Thanks to the nice formatting of Visual Studio the logical blocks were a lot easier to identify than in the original code. And I could start unravelling the goto statements one by one.
From this experience I have to say that there are some cases where goto statements are actually VERY useful to avoid having to rewrite the same code over and over again, although in a lot of cases the same can be achieved by using methods and calling those repeatedly.
I also used the free version of Silverfrost to compile the original code and perfrom regular checks on my reformatted code to ensure that the reformatting didn't produce errors.
A generic approach to "decompiling" such a code would be the following:
LLVM's own C backend can provide you with a first draft.
The best way without doubt is to first rewrite/refactor the FORTRAN code into a better structured and logical way. This will force you to understand the original logic before attempting to port it to C#.
Here's how I would approach it:
Don't waste your time with an automatic code converter which will just end up with the same mess of goto statements as the original FORTRAN since C# supports gotos and labels, just as C does.
Failing anything else, you can use goto statements in C#.
The goto statement transfers the program control directly to a labeled statement.
A common use of goto is to transfer control to a specific switch-case label or the default label in a switch statement.
The goto statement is also useful to get out of deeply nested loops...
To convert any old FORTRAN code to a new language somebody should go through some basic steps in your legacy code (1) for static type checking convert the code to "IMPLICIT NONE" (2) convert all truncated common to full common (3) Remove equivalence (4) convert common to Module of FORTRAN 90
Then you can try to convert to other languages.
