Fortran to VB translator - an update

A few weeks ago I mentioned I am working on a Fortran to VB translator
because of a contract I accepted. Some people commented to me (in a
polite way) that I was crazy for taking on an impossible task (since
the first Fortran compiler took 18 man years), someone pointed out
that the current program around doing Fortran is something like 27,000
lines of C code, and some said if I'm doing this comprehensive a
project I should be charging hundreds of thousands of dollars based on
the time involved.


Well, maybe that is true, but except for some minor touches I am
essentially finished. While these are preliminary numbers, they show
two things (1) a translator is much less complicated than a compiler
(2) it isn't as difficult to translate FORTRAN into Visual Basic as it
is to do other languages (3) while it was a bit of work it wasn't as
bad as I feared it might be and (4) if I'd known what I was in for
when I bid on the job I'd probably have charged more!.


Having done this I now understand some of the things they do in
compilers where I've read the sources, and why the code they process
is often scanned at a byte level and token identifiers created from
lookahead of what symbols are coming up next. Because it makes it
easier to track where you are in the code and know what you have to
translate.


The following numbers for the translator include comment lines but do
not include blank comments nor blank lines.


The translator itself is 5309 lines of code in 5 forms and 38 modules.
The run-time library is 908 lines of code with 1 form and 4 modules.
Additional code will be needed to cover certain additional functions,
perhaps another 4 or 500 lines. So basically I am estimating this
program will have taken about 7000 lines of code in Visual Basic.


There is the possibility it might have been a smaller program (or
maybe it would have been larger) if the program was not 1-pass.
That's right, it's a one-pass translator. And it does a fairly good
job too. I'd say it gets about a 90% based on the code I'm
generating. There are some things it can't do correctly and require
manual translation. For example, a Fortran EQUIVALENCE statement has
an equivalent (no pun intended) in Visual Basic, but it will only work
for non-local variables, you can't use it for variables that are local
to a single SUB or FUNCTION, you can only do it for variables that are
declared for an entire source file (a module).


The translation speed of the translator is amazing for something
written in Basic. The sample application I am using for testing
consists of 89 fortran source code files, less than 10 being include
files and the rest plain source code, amounting to 16,237 lines of
code, as counted by the translator program.


I wasn't trying for speed, I was trying for accuracy in translation
and it does appear to provide that, based on examinations of the
original Fortran source and output translated to Visual Basic.


On my E-Machines 333, which is an AMD K6 processor running Windows 98
at (obviously) 333 mhz, it took 45 seconds, for a translation speed of
361 lines per second.


On my Hewlett Packard Pavillion which is an Intel Celeron running
Windows XP home (Service Pack 1) at 2.7ghz, it processes the same code
base in 15 seconds, for a translation speed of 1160 lines per second.


It's a lot faster than I expected it to be. I would have been
delighted with 1160 lines per minute. After all, you only have to
translate the code once, after that you work with it as Visual Basic
code from then on. I was really amazed at what I have accomplished.


Maybe it goes to show that sometimes when you don't know it's
impossible you can get some really great things done!

Return to the comp.compilers page.
Search the comp.compilers archives again.