The ENTRY statement provides an alternate entry point into a function or subroutine program unit. This allows slightly different procedures to share large blocks of common code.
Before I go into depth with this statement there is some basic background information that you should know about this statement. In the early years of FORTRAN programmers looked for anyway to reduce the size of their code in order to cut back the amount of memory required as the program executed. The entry statement was invented to help programmers do just that. Programmers became aware that often times they were writing functions and subroutines that contained similar code with only a few minor differences between them. So to save space, the Entry statement was used to consolidate these subprograms into one lump of code by utilizing the fact that they required large chunks of similar code. Now that you know the history behind this statement, the best way to understand how it works is through the use of an actual example. In fluid mechanics it is often necessary to calculate the head loss ( energy loss ) through a pipe. Head loss is a function of several variables and is dependent on the type of flow through the pipe. The following example shows a small part of a main program that calculates the fluid's Reynolds number and then calls one of two functions to give an estimate of the head loss. Please note that this is an oversimplified example. To get a good estimate of head loss is actually more complicated then this example seems to indicate. It has only been simplified, so that you don't have to struggle through a few hundred of lines code in order to figure out how the ENTRY statement works
Re = (rho*v*dia)/u len = 50.0 if (Re.lt.2100) then loss = func1(len,dia,v,Re) else if (Re.gt.4000) then loss = func2(len,dia,v) else go to 2000 end if...
Function func1(len,dia,v,f) real func1,func2,dia,len,v,f,hloss,g,f1 f1 = 64.0/f go to 120 entry func2(len,dia,v) f1=0.02 120 parameter g = 9.81 hloss = f1*(len/dia)*(v**2/(2.0*g)) func1 = hloss func2 = hloss return end
From the highlighted text, you can see that the function func2 doesn't begin with a function statement, as you would normally see. Instead, it is inserted in the middle of func1 by the use of the entry statement. When func2 is called, the program goes to the line where the ENTRY statement begins and starts execution of all the code below it. Despite the fact that all of the type declaration statements appear before the entry of func2, all of the types that they declare are still in effect in for the execution of func2. When func1 is called, the program will start at the FUNCTION statement and execute all code up to the go to statement. At that point, it will loop over the statements that pertain solely to func2 and keep on executing all code from statement label 120 to the END statement. Finally, notice that at the end, both func1 and func2 are set equal to hloss. This is necessary in order to ensure that the proper result gets reported back to the main program no matter which function was called.
As you may have suspected, there are few rules that go along with the use of the ENTRY statement that were not covered in the above example. First, the ENTRY statement itself can appear anywhere after the initial function or subroutine statement except inside of an if block, a do loop an interface block or inside of a derived type definition. Also, any dummy arguments that appear in an entry statement can not be used by the subprogram until that ENTRY statement unless they were also used as dummy arguments in the initial function or subroutine statement or in a previous ENTRY statement. Finally, the name of the function that appears in the ENTRY statement can not appear before the ENTRY statement ( except in a type declaration as shown in the above example ).
As you can see from both the example and the brief listing of rules governing the use of the ENTRY statement, its use can lead to some complex code. Although its use can reduce the number of lines of code you need, the fact that it can develop some complex code makes the program more susceptible to errors. This is why this statement is not used very often in new programs. In fact, its use is getting so scarce that this statement may be in line for removal from a future FORTRAN standard.
Written by Jason Wehr: firstname.lastname@example.org and Maintained by John Mahaffy : email@example.com