I once worked on a project to convert 200,000 lines of Fortran to C. Mostly F77 with some F4. Fortran and F4, especially in control-flow, is a fairly primitive

I once worked on a project to convert 200,000 lines of Fortran to C. Mostly F77 with some F4. Fortran and F4, especially in control-flow, is a fairly primitive language. 200K F77 is probably around the same size and complexity of 200K lines of IBM assembly. Computed GOTOs and other constructs that cannot be directly transformed to "structured" code flow. You can jump into and out of the middle of loops or subroutines. We looked at a F2C compiler process. This would have been exactly analogous to the Wang method. It produced working "C" code, but it was unreadable implementation-level gobbledy-gook. But we, like the IRS, wanted to maintain this product forward in the target language "C", as if it had been originally written in it, if possible. What we did worked extremely well. It took a bit over 3 man years with about two people. #1 - we had test cases. And if there was code that the test cases didn't hit we added it first. The IRS has a few hundred million returns a year and could easily make, say every return for the last 10 years, into a "pretty exhaustive" test suite. #2 - we did an incremental approach. We did NOT convert the F4/F77 into requirements and then do a clean-room top-down re-implement. It would never have worked. We arranged the system so we could run the program with the original F4/F77 and new C in parallel. We replaced one Fortran procedure with C at a time while keeping the test cases working. In assembly, even the definition of a procedure can be nebulous. But what you do is discover the 10-20 idioms of the assembly procedures, functions, reuse, etc. and tease out how to replace with "C" or ??? If this is a big issue, use either IDA Pro or Ghidra. If they don't support IBM assembly, then that's the first subcontract you let. #3 - My partner was fastidious. Instead of the test cases simply passing, he added the self-imposed restriction of bit-identical outputs. It took work but it was possible. One function/procedure at a time, one line at a time, the system was converted from old to new. All the time it produced bit-identical outputs for all tests. In the IRS case, the test cases should be every return ever processed yields bit identical results. #4 once the last F4/F77 was removed, any C that was not idiomatic C was lifted and rewritten in a normal procedural style. Stuff like weird state machines to simulate computed GOTOs and non-structured code. This refactoring, again, was bottom up and was tested to bit identical results of all tests (which is kind of excessive!) At the end we had a maintainable "high-level" language (C, yes, yes HN) exact equivalent. This is the kind of task where rigor and bottom up is precisely what is needed and is actually much more effective. Someone should do an FOIA act to get the source and then do a nice dissertation or senior project to do this and produce maintainable Java (and/or something nicer). I find the timeframe and budget the IRS proposed to be ridiculous and the odds of success negligible. A good hacker or two could do this with a 100th the resources. Epilogue: I believe this process was completed about 15 years ago. Since then, the system remains in constant heavy use. There have been exactly ZERO bugs due to the conversion. We later moved the system from an antique RISC environment to x64 Linux. This exposed 2-3 bugs due to word length and endian-ness, that process (since it was already standard C) took one person about 3 months.