On 3/24/20 6:06 PM,
ga...@u.washington.edu wrote:
> On Tuesday, March 24, 2020 at 2:11:09 PM UTC-7, Marshall Ward wrote:
> [...]
>> There is also this deprecated ENTRY thing, which I know nothing about.
>> But they seem to be considered procedures.
>
> This one I can explain. Sometimes it is useful to have two different
> functions or subroutines that share code. Consider, as a common example,
> a function to compute SIN and COS. They use the same polynomial
> expansion, but with different argument reduction. Traditionally,
> they were written in assembly, but now are more commonly in a higher
> level languages, such as C. (But C doesn't have ENTRY!)
>
> In any case, you could have a function to compute SIN, with an ENTRY
> to compute COS. They each do the appropriate argument reduction,
> and then go to common code to use the appropriate expansion.
I think this is a good description. In modern fortran, you can do these
same types of things by defining a module that has some entities
defined, maybe expansion coefficients for special functions, or roots
and weights for gaussian integrations, and things like that. Then within
the module, you have several contained functions or subroutines that
share those entities.
Before modules were introduced, the only way to share data like that
between different subprograms was through common blocks or with entry
points. With common, those variables were global, even when they didn't
need to be. So that left entry points. In most of the subprograms with
entry points that I wrote, the main subroutine was never called. Its
only purpose was to define the local variables that were shared and to
define the dummy arguments that were later used by the entry points. I
think the entry point dummy arguments are required to be a subset of the
main subroutine dummy arguments. So there were lots of odd quirks when
using this feature to write programs. With f77, things were cleaned up
al little because of SAVE. You could SAVE the shared variables, or the
common blocks, so they did not need to be declared elsewhere, and you
knew they would survive between entry point calls. The typical
subprogram structure was like this:
subroutine top( arg1, arg2, arg3,...)
integer arg1, arg2,...
real arg3, arg4...
save ...list of shared local variables...
data / ...initialization of those saved variables.../
entry sub1( arg1, arg2,...)
...do whatever...
return
entry sub2( arg1, arg3,...)
...do whatever...
return
entry sub3( arg4, arg5,...)
...do whatever...
return
end
In the calling program, the entry points would be called in the normal way:
...
call sub1( i, j )
...
call sub2( k, x )
...
This means that the linker had to recognize the entry points in the same
way that a subprogram was defined and referenced.
Dummy arguments could be shared by several entry points, but I think
they all had to be a subset of the top subroutine argument lists. All of
the declarations had to be for the top subroutine, there were no
declarations allowed later within the entry point code.
If you did not have a return statement after one entry point, then
execution would just keep going past the next entry point until a return
statement was finally executed. Sometimes this was on purpose, sometimes
it was just a programming oversight. With GOTO, you could write
spaghetti code that could jump around between entry points.
Only dummy arguments that were defined in the entry could be referenced.
Some compilers relaxed that requirement, and you could call one entry
point to define the association between actual and dummy arguments, and
then you could call other entry points and it would remember that
previous association. This was done mostly to shorten argument lists for
the subsequent entry point calls. With modern fortran, you might do
something like that with saved pointer variables.
If the top subprogram was a subroutine, then all of the entry points had
to be subroutines; if it was a function, then all of the entry points
had to be functions. If I remember correctly, the entry points could not
call each other, the only allowed references were from outside.
There were lots of little quirks when programming like this. Things are
much better now with modules and contained procedures.
$.02 -Ron Shepard