Steps For Converting Fortran 77 Code To MatLab Functions

Written By: Christopher Vollick Last edited: March 13, 2008

The Conversion Process

The majority of the the conversion process is automated, but the program currently has some limitations that require human intervention. Some of these, if not looked after, will not cause a problem with the translation process, but will cause syntax errors in MatLab. Others will not cause an immediate problem with the translator but may generate invalid code. Others may cause the translator to crash, resulting in no output. In any case, none of them result in working code and they must all be xed before translating.

Limitions
The user needs to make sure that none of the following are used in the FORTRAN code before the translation can take place. Grouping and repetition in FORMAT statements are not supported, these need to be expanded by hand All command names to be translated must be all captials. If they are not they will not be corrected. Also, the lowercase end should never appear in the source le, as this will cause a problem with the translation. The translator only supports the old method of DO loops and IF statements. DO label VAR=start,end IF (CONDITION) STATEMENT There is no support for ENDDO or ENDIF, and IF statements can only execute one command I use the term functions fairly often when refering to both TCLs proc and FORTRANs SUBROUTINE and PROGRAM areas. FORTRAN has a FUNCTION area that takes in a number of arguments and returns a

single value. The translator does not support FORTRAN FUNCTIONs. The translation will fail if any are included. SUBROUTINEs can be called from more than one place in the code only so long as the kinds of arguments are the same at each call statement. By kind I do not mean integer vs oat etc, youll have to check the Functions section for more information. Write statements can not use Implied Do-Loops Write statements only print to the screen regardless of the destination given in the FORTRAN code. Write statements must use a FORMAT statement, and must refer to it by line number. You currently cant use WRITE(*,*) or WRITE(*,FORMAT). You can pass a function handle into an other function, but the converter doesnt do this automatically, after the conversion you have to add the @ sign yourself A GOTO statement located inside a DO loop can not point at a label that is outside the DO loop. Im not sure what you can replace it with that is acceptable. Be creative, or try modifying the translator (This is not recommended) A limited number of intrinsic functions are supported, only what was required to translate the given problems, and nothing more. If the le you want to convert has functions besides these, they will need to be added to the translator. Below is a chart listing the currently supported functions, along with what they are converted into. There is also a section later on in the document about the translator itself and how to make changes to it. Fortran Instrinsic Function [II,I,KI,D,Q,C,CD,CQ]ABS(x) CONTINUE DFLOAT(x) IMPLICIT IF (CONDITION) STATEMENT MatLab Counterpart abs(x) An empty string x % if(CONDITION) STATEMENT end (abs(x)*sign(y)) max([x,y,z...]) min([x,y,z...])

[D,II,I,KI,Q]SIGN(x,y) [I,AI,A,K,AK,I,K,D,Q]MAX(x,y,z...) [I,AI,A,K,AK,I,K,D,Q]MIN(x,y,z...)

Translating
Once these restrictions are checked and corrected the translation can begin. The translator is a program written in TCL, so you must have TCL installed 2

on your computer in order to use the translator. If you are using Windows, the command to start the translation from the command line is tclsh83 f2matlab.tcl FILENAME [OUTPUT-FILENAME] Your version might not be tclsh83, but something similar. On unix the command is tclsh. If an output lename isnt given, one will be created by taking the name of the input le and pulling o its extension and adding .m to the end. For example, lename.f will output the result to lename.m. If neither an input le or an output le are given then it will read o the standard input and output to standard output. If you are unclear what this means, I suggest you dont use this feature. It is rarely useful.

Potential Problems
The translator does not debug or even check the FORTRAN code. It is assumed to be correct. The translator will tell you what part of your code it is currently converting, but will most likely not give you any warnings. There is very little error checking and if there is a failure either the MatLab code will be incorrect or the translator will crash. If the translator should fail the best thing to do is nd out what it was processing when it crashed and read the above limitations to see if you have used something the translator doesnt support. If you still cant see anything wrong, I suggest the translator be debugged to nd out where it is failing. Whoever has this task should read the section of this text describing the code and the concepts Ive used, so they can better understand what should be happening.

The Translator Code

Preamble
The code for the translator is written in a language called TCL. If you dont know TCL I suggest you learn it before moving on. While it is possible to make modications the the code without knowing the language, the chances of succeeding drop dramatically, especially with more involved changes. Also, even if you know the langauge I suggest you make a copy of the code and change that, so that if you should fail youll have something to fall back on. This is very important if you dont know the code very well, as some of it makes assumptions, and if you dont know about them a small change in one function could crash another function entirely. It would also help to know regular expressions, and how TCLs regexp and regsub commands work. I make heavy use of regular expressions in this, and if you dont know them it may be hard to nd out some of the things being done. Ill try my best to outline as much information as I can, and explain any obscure issues as they come up, but even I dont know them all.

Considerations
The translator uses many phases to complete its task. At the beginning it reads in the entire le, then it runs over each line of the le many times changing things related to whatever phase the code is currently on, before writting the nal result to the chosen output medium. As a result, if the code fails at some point, no output will be produced. Also, at no point should the source le be modied. If this happens something terrible has occured. Also, the le is changed multiple times in memory, with each phase making changes to some aspect and leaving the result as the starting point for the next phase. In the code this variable is called Contents and it exists globally between all of the procedures that represent the various phases. Most of the procedures break this string up at the line breaks into a list. Then, they join the list back together with line breaks at the end. This allows the conversions to happen one line at a time, which is much easier. While it may be more ecient for the program to only break up the Contents into lines once and just use that and join the list together at the end, there are a number of reasons why this isnt done. First, most functions rely on the les contents being represented as a list of lines, but not all of them do. Some work on the whole le. Also, a number of conversions are made by expanding a line into three or four lines. Then, when they are joined together and broken up again in the next phase, the result will reect the changes made in the previous phase. While this could be done as a list, quite easily infact, it is not recommended changing the structure of a list while you are iterating through it. Changing the current element is less of an issue. I run into this issue later, while dealing with GOTO

statements, but since eciency of translation is mostly unimportant, this is much simpler and less error prone.

The Phases
As has been said earlier, the translator goes through a number of phases with each phase being represented as a seperate procedure. The procedures, and what they are responsible for, are listed below. Setup: This procedure handles the command line arguments and opens the neccesary channels to allow le access. It also lls the Contents variable with the contents of the input stream. PreProcess: This procedure does a number of simple things required for the next functions to work. One extremely important thing it does is join the lines that have been continued (With a character other than a space or 0 in column 6) into one line. Every phase after this just ignores the possibility of continued lines. It also makes the FORTRAN comments into Matlab comments (%), and adds a PROGRAM MAIN to the start of Contents if the original le had its rst executable (Not commented) line not start with PROGRAM or SUBROUTINE. This is because MatLab, and therefore this translator, requires every line of code to belong to a function of some kind. Later phases assume this. The last thing it does is to try to standardize the startings of lines. If a line has a 0 in column 6 or starts with a tab, it is changed to start with 6 spaces. This just makes the lines a little bit more predictable for future phases. DoLoops: This procedure changes FORTRANs DO loops into MatLabs for loops. This is described in more detail in the section on DoLoops. Goto2: This procedure changes FORTRANs GOTO statements into something that MatLab can handle, without changing any of the logic. The reason for the loops and the like in the Main routine surrounding the Goto2 statement is because Goto2 operates on a per routine basis and cant be called on the whole Contents. It needs to be spoon-fed the contents of the SUBROUTINEs. More information can be found in the Goto2 section. Variables: This procedure has a couple of jobs related to variables. In general, it travels through the le, line by line, looking for variable denitions. It also keeps track of which subroutine or program block its currently working through. Because of this, there cant be an END in the code that doesnt end a SUBROUTINE or PROGRAM, because the translation will most likely fail. When it reaches a variable it decides whether or not its an array. If it is, it logs the variable in the global array Functions for later comparison in the Functions procedure discussed later. It also sets it so that if a variable doesnt exist, it is initialized to 0. 5

Word Replace: This procedure does the simplest forms of translation. It starts o by going through the le and nding all of FORTRANs operators and changes them to MatLabs. It also nds things to be translated oneto-one. For example, it changes .FALSE. to 0 and ABS to abs. Then it does a few more complicated translations. These are because there is no one-to-one equivalent in MatLab. MAX(x), needs to become max([x]), so some data handling needs to be used. There is more information on how to add new functions to Word Replace in the Word Replace section. Functions: This procedure handles turning SUBROUTINEs and PROGRAMs into functions. Most of this is simple, but there is also a lot of processing done on arrays to get them to function like FORTRAN expects them to. It should be noted that, like the variables function, it expects the only END commands to end PROGRAMs and SUBROUTINEs. If there are END commands with other purposes than this, it may fail. More information is discussed in the Functions section. Formatting: This procedure handles changing FORMAT statements and WRITE statements into fprintf statements. This method uses the ConvertFormat helper routine to do the actual translation from FORTRAN FORMAT string to MatLab format. Then, these translated statements are saved by line number into the global Formats array. Then, it travels through the le changing each WRITE statement into a printf using the already computed format string. PostProcess: This function handles all the cleanup. It goes through each line and removes any labels left behind before it makes it to MatLab and adjusts the indenting such that the document looks well formatted when viewed later. Finally, it ends almost every line with a semi-colon. In MatLab, an error is thrown when anything follows the last end statement of a function, including a semi-colon, so it doesnt put a semi-colon at the end of end lines. Also, it doesnt put one on blank lines, because that doesnt look good. Close: This routine doesnt do anything related to translation. It just closes the streams, assuming theyre not stdin or stdout. Other Functions in the File forEach: You may notice this function used extensively. I wrote this function to copy the existing foreach loop, adding the feature that any changes to the variable through the loop are changed in the list. As a result, rather than its second argument being a list, it is now the name of a list variable. Any time within the loop the variable whos name is given in the rst argument is changed, that corresponding item in the list variable is changed.

Also, the variable that holds the current index is made accessable, which allows you to both read it and nd out which item in the list you currently have access to, and change it to skip list items or go back. Gotos: This function is a rst attempt at breaking up gotos. In simple cases it will do the same thing as Goto2, but in a little uglier way. Its major downfall is that it cant handle jumping in for loops. This is what prompted the creation of Goto2. Unlike Goto2, Gotos is called without arguments and operates on the global Contents variable like every other phase. Only Goto2 is passed its source. There is no reason to use Gotos, but I refuse to delete it. Some parts of it may be useful later. ConvertFormat: This function is mentioned briey in the description of Formatting. This is the function that takes in a FORTRAN format string and turns it into a MatLab (And therefore c) printf format. GetArg: This function takes in a string that represents an argument list (var1,32,Array(2,3,4),0) and an index starting from 0 and returns the argument at that position. It is built to take brackets into account, and in the example given GetArg would return argument 3 as Array(2,3,4), not Array(2 as a blind comma search would. GetBracketLimits: This function takes in a string and returns a list with 2 numbers in it. The rst number is the index from the start of the string to the rst (. The second number is index from the start of the string to the matching ). This also takes nested brackets into account, so Go(Mark(2),Index) will return the index to the rst ( and the second ). GetBracketContents: This function is an extension of GetBracketLimits. It takes in an input string and passes it to GetBracketLimits. It then uses the indices returned by GetBracketLimits and returns the actual string between the brackets. So if it was given Go(Mark(2),Index), it would return Mark(2),Index, not Mark(2 as a blind bracket search might. BreakVarList: This function takes in a string that represents an argument list (var1,32,Array(2,3,4),0) and returns a list that is each item in this list, taking brackets into account. In this case it would return [var1 32 {Array(2,3,4)} 0], where as a split command would return [var1 32 Array(2 3 4) 0], which is not as helpful. This command is the engine behind GetArg. lsearchAll: This function takes in a list and a regular expression and then returns a list of the indices of all of the items in that list that match the regular expression. In the most recent version of TCL this is supported directly by the lsearch command, but in the version I was using it wasnt, so I had to write it myself.

Word Replace
This is the section that will has the highest probability of being edited. This function is the one in charge of the translation of FORTRAN functions to MatLab ones. If you have a function in your FORTRAN code that the current translator doesnt support, you would add it here. There are a number of examples of dierent kinds of translation in the function already. Almost all of the translations involve a list that has its items in pairs, with the rst item being the pattern to replace, and the second item being what to replace it with. The rst translation takes care of operators, that is only things that come after equals signs. This is so that an asterisk, addition sign, or slash dont get translated if they should show up somewhere where they dont have anything to do with math. The next thing is other operators. This could be used to translate other things, but its better to keep them seperate from a organization standpoint. All it does is to use regular expressions to nd one pattern and substitute it for another. Next it translates FORTRANs instrinsic functions to MatLabs. These rst ones, in the list, are functions that have an exact match in MatLab. You can see from ABS a method of capturing all of the variations FORTRAN has to deal with multiple types and replace all of them with one MatLab function. Also, you can see DFLOAT gets changed into nothing. This is because MatLab doesnt need a function to convert to a oating point number. INTRISIC gets changed into a comment because it is unneeded in MatLab. After these are the special cases. There are also a number of examples here. IF statements exist in MatLab, but they cant be translated one to one because there needs to be an end statement after any commands. The max and min functions need small changes, but they require a dierent kind of analysis. The SIGN function in FORTRAN doesnt even have an equal in MatLab, and it needs to be translated into a series of commands that accomplish the same thing. Notice how the series of commands are put in brackets. This is important to make sure the correct value is used, and order of operations goes as the original FORTRAN code expected. When adding a new translation, the rst thing to decide is what exactly you want the translation to do. After this you can decide where the new function can go. If it is a simple conversion you can put it in the list of one-to-one translations and be done. If it is more involved you may need to use one of the already existing translations as a template on how to make your own. After youve successfully added your new function, please add it to the list in this le so that someone else knows it is now supported. To do this you may A need some experience with L TEX, which is the language I used to typeset this document. You may not, if you can follow along and just gure out how the table works using cut, paste, and modify.

DoLoops
The DO Loops are the rst things really translated. In FORTRAN the supported DO Loops look as follows. DO label VAR=start,end[,step] And this loop will run the statements immediately after itself up to and including the statement labeled with the given label. At which point VAR will be incremented by step, or 1 if it isnt given, and continue to do this so long as VAR is less than end, at which point it doesnt go back to the DO loop after label. In MatLab, this is almost exactly a for loop. First it captures a line that follows the above pattern and changes that line to read for VAR=start:step:end Where step is a 1 if a step isnt given. Then it puts the label its looking for onto a stack. If you are unfamilier with the concept of a stack, I suggest you look it up. Then, when it reaches a label, it checks to see if it is the top item on the stack. If it isnt it moves on, but if it is it adds an end after the current line and removes the top item from the stack. At this point it also checks to see if this next item is also the current label, and adds another end and so on until the stack no longer stops at this line, then it moves one. This is to work properly in the case where two or more nested loops (Loops within loops) end on the same label. For Example: DO 15 I=1,10 DO 15 J=1,10 X=I**J

15

Goto2
Perhaps the most important part of the translation process, along with the Array conversion that will be described in the Functions section, is the conversion from GOTO statements that FORTRAN uses with great frequency to something that MatLab can use to achieve the same eect. The method I decided on is probably not the best, but it is the simplest and most reliable. It works on a per routine basis. What Ive done is used the labels to break the code up into blocks containing all of the code from one label until just before the next line with a label, making a number of disjoint segments of the routine.

Example
x=1 IF (MOD( x , 2 ) ) GOTO 10 WRITE( , 1 ) x FORMAT ( I1 , i s Odd ) GOTO 20 WRITE( , 2 ) x FORMAT ( I1 , i s Even ) RETURN x=1 IF (MOD( x , 2 ) ) GOTO 10 WRITE( , 1 ) x FORMAT ( I1 , i s Odd ) GOTO 20 WRITE( , 2 ) x FORMAT ( I1 , i s Even ) RETURN

0 1 1 2 10 2 20

1 10 2 20

Notice a couple of things here. 1. Each block is given a number, starting from 0. 2. Each block after the rst one is created to start with the line that has the label on it and end before the next labeled line. 3. Labels that identify format statements dont aect the block structure, they are ignored. 4. It cant be seen in this small example, but by the time the translation reaches this point all of the for loops would already be formed. A for loop is always put into its own block, whether its labeled or not. The reason for this will be explained later. Now that the code is seperated into blocks, there needs to be a mechanism for moving from one block to another. For this the entire code is put into a while loop and switch statement. while 1 Block=0 s w i t c h Block case 0 x=1 IF (MOD( x , 2 ) ) GOTO 10 WRITE( , 1 ) x 1 FORMAT ( I1 , i s Odd ) GOTO 20 case 1 WRITE( , 2 ) x 2 FORMAT ( I1 , i s Even ) case 2 RETURN otherwise break end Block=Block+1 end 10

Now the code will start at the top and start at block 0, and when its done with block 0 it will increment Block at the bottom of the loop, loop back to the switch statement again, and continue until it hits the RETURN. If there doesnt happen to be a return, the break in the otherwise statement will make sure that the code moves on like it should. Now that we have this set up, all we have to do to move from one block to another is to change the value of Block and reset the loop to the top again. The MatLab command continue, is used to go back to the top of the loop. The nished routine looks like this: while 1 Block=0 s w i t c h Block case 0 x=1 IF (MOD( x , 2 ) ) Block =1; c o n t i n u e WRITE( , 1 ) x 1 FORMAT ( I1 , i s Odd ) Block =2; c o n t i n u e case 1 WRITE( , 2 ) x 2 FORMAT ( I1 , i s Even ) case 2 RETURN otherwise break end Block=Block+1 end While this is the general concept, it does get more complicated. Any for loops in the code need to be delt with on their own, because there can be jumping within a loop, and you cant break up a loop in the middle and try putting them into dierent blocks, it doesnt work. As a result, for loops are always put into their own blocks. Then, when a block is identied as being a for loop, the function calls itself on the contents of the for loop, breaking it up exactly as the outside might be broken up. After that, the new contents of the for loop that are returned by Goto2 are copied into the body of the loop.

11

Example This is the contents of a SUBROUTINE as it might be sent into the Goto2 function. Notice that the code block has already been through the DoLoops procedure and has complete for loops. Loop=4 IF ( Loop .GT. 5 ) GOTO 30 f o r x = 1 : 1 : Loop IF (MOD( x , 2 ) ) GOTO 10 WRITE( , 1 ) x 1 FORMAT ( I1 , i s Odd ) GOTO 20 10 WRITE( , 2 ) x 2 FORMAT ( I1 , i s Even ) 20 CONTINUE end GOTO 40 30 WRITE( , 3 ) 3 FORMAT( Loop i s t o o high ) 40 RETURN Now the translator will break up this chunk into blocks and when it reaches the inside of the for loop it will pass the contents of it to another Goto2 procedure. You may notice that the contents of the for loop is almost exactly the previous example, this is to show that the contents of the for loop will be replaced with the result of that last example. The result of the conversion can be seen below.

12

while (1) Block=0 s w i t c h Block case 0 Loop=4 IF ( Loop .GT. 5 ) Block =7; c o n t i n u e case 1 f o r x = 1 : 1 : Loop while 1 Block=2 s w i t c h Block case 2 x=1 IF (MOD( x , 2 ) ) Block =3; c o n t i n u e WRITE( , 1 ) x 1 FORMAT ( I1 , i s Odd ) Block =4; c o n t i n u e case 3 WRITE( , 2 ) x 2 FORMAT ( I1 , i s Even ) case 4 RETURN otherwise break end Block=Block+1 end end case 6 Block =8; c o n t i n u e case 7 WRITE( , 3 ) 3 FORMAT( Loop i s t o o high ) case 8 RETURN otherwise break end Block=Block+1 end A few things to note: 1. The code does become noticably longer and more complicated, but it works identically to FORTRAN. Ideally, the MatLab code shouldnt have to be read or debugged, so while it is unfortunate that the resulting algorithms are much more complicated, it should function the same on the outside. 13

2. Youll notice that the Blocks in the for loop start at 2, which is the next block number since the for loop is in block 1. 3. Other than the dierent block numbers and the RETURN statement turned into a CONTINUE, the contents of the for loop are the same as the rst example we translated, just copied into the body of a for loop. 4. The for loop is always a block on its own. Even though there was only one command following the for loop, it needed to be put in a seperate block. 5. There isnt a block 5. This is intentional. The for loop only has up to a block 4. After block 4 the loop increments Block to 5, hits the otherwise command and jumps out of the loop. Now the code is at the end of block 1 with Block equal to 5. Since its at the end of a block it moves to the bottom of the loop, where Block is incremented again to 6. Now it makes it back to the top of the loop. Everytime there is a loop, one block isnt used. 6. The Goto2 function assumes that the only end it will nd will be the one ending a for loop. Thus, if there is an end in the source le this routine will most likely fail. It may complete without crashing, but it will not run properly in MatLab.

Functions
For the most part the conversion of functions are simple. There are a couple of things that need to be taken care of before it will work properly though. Kinds of Input First, there are 5 combinations of input conditions that all require special consideration. Value as a Value: This is the most standard kind of input. This is a variable that is input to a function, and it is used as a variable inside the function. Constant as a Value: This is also common. In this one of the arguments to the function is a constant (2,32.5,etc), and it is used as a variable once inside the function. Array as an Array: This is similar to the Value as a Value. In this case an entire array is passed into a function, and once inside the function uses it an an array. Array Index as a Value: This is where a specic item from an array (Temp(3))is passed into a function, and once inside it is treated as a normal variable.

14

Array Index as an Array: This is the one that causes the most trouble. FORTRAN and MatLab agree almost completely on all of the above input types. They disagree completely on this though. The best way to describe this is with an example. (FORTRAN) ... DOUBLE PRECISION x ( 6 ) x=[1 ,2 ,3 ,4 ,5 ,6] CALL P( x ( 2 ) ) ... SUBROUTINE P( Array ) DOUBLE PRECISION Array ( 2 ) Array (1)=99 Array (2)=100 END In this example the array x gets lled with the numbers 1-6. Then the second index of x gets sent to P. Here its called Array, with Array(1) refering to x(2) and Array(2) refering to x(3). Thus, when P is done x is equal to [1,99,100,4,5,6]. In MatLab: ( MatLab ) ... x=[1 ,2 ,3 ,4 ,5 ,6] [ x ( 2 ) ] =P( x ( 2 ) ) ... f u n c t i o n [ Array ]=P( Array ) Array (1)=99 Array (2)=100 end This is what the function would have been translated to in the simple case. In this case the top part does the same thing as FORTRAN until it gets to the function call. Now, it sets Array to the single value of 2 (which is x(2)), but in MatLab everything is an array, so Array(1) is 2 and Array(2) is nothing. Then it sets Array(1) to 99, and then creates a new space on the end of Array for the value of 100. Now it tries to return Array, but now Array is of size 2, and x(2) is the single element 2. Now theres an error that complains because an array of size 2 is trying to be inserted as an item into an array of size 1. It doesnt work. Instead the above function would be converted into this:

15

( MatLab ) ... x=[1 ,2 ,3 ,4 ,5 ,6] [ x]=P( x , 2 ) ... f u n c t i o n [ Array Array ]=P( Array Array , A r r a y I n d e x ) Array=r e s h a p e ( Array Array ( A r r a y I n d e x : . . . ( Array Index 1)+2) ,2 ,1) Array (1)=99 Array (2)=100 Array Array ( A r r a y I n d e x : ( Array Index 1)+2) . . . =r e s h a p e ( Array , 2 , 1 ) ; end Which works as FORTRAN expected. The process this is all done by, along with every other kind of input is outlined below. The Process The rst thing that is done is it goes through the le line by line and nds each call statement. Then it records whether or not the input arguments are array indexes or not. This is why a certain function can only be called a certain way, because the next time it runs into a call statement, it will change to use this new data instead. It also keeps track of what line it found the call statement on because it will have to come back to them later. Before this, the Variables function found each subroutine and looks at the variable denitions to see if in the subroutine it is declared as a value or an array. Then the Function process checks if it is both declared as an array and it is passed an array index and if it does, then it does a couple of things. 1. It seperates the array from the index, so both are passed in seperately. 2. It makes sure that the same array is only passed in once, and every argument after that that passes in the same array with an index, only the index is passed in. 3. It adjusts the output arguments so that only the array is returned, not the index, and the array is only returned once per SUBROUTINE. 4. It adds a command to a running string of commands to be executed before the rst line of the subroutine to reshape the array (See above example to see what it looks like). 5. It also adds the reverse command to a running string of commands to be executed before every exit point of the subroutine.

16

6. It adds the number of the argument to a list of arguments that have been changed. This is so that the call statements can be reformed to use the new arguments instead of the old ones. Also, regardless of what kind of input it is, it adds a statement that sets the variable declared to 0 if it doesnt already exist. Next, it continues through the le and on the next line it adds the resizing command. Then it moves through the le and any time it reaches a return statement it adds the exit-point commands before it to ensure that the correct data is returned. If it hits an end command the exit-point commands are written then cleared and a new subroutine is moved onto. After all this the procedure revisits all of the case statements it has found and makes the changes required to have the call statement give the right data to the new function. While its there it also reformats the call statement to be MatLab compatible. It checks to make sure that the same array is only passed in and out once. Also, if the input is a Constant, then the output variable must be a dummy variable, that is one that is never used for actual data.

Conclusion

The purpose of this document was to rst explain to someone how to use the existing translator to convert FORTRAN 77 code to MatLab. The second section tried to explain most of the larger ideas in the code so that someone with moderate TCL knowledge could have a chance to modify it if need be. Hopefully I succeeded somewhat and have given you enough information to make any modications.

17