Prev: Passing optional parameters
Next: Renaming module procedures
From: glen herrmannsfeldt on 4 Oct 2009 08:40
David Weatherall <nospam(a)nowheren.no.how> wrote:
(snip of question regarding ENTRY and dummy arguments)

< I've been away in UK for a week so apologies for the late reply.

< I see your point, and I know you know more about Fortran than I ever
< will, but isn't it the case that x and n are different TYPE
< definitions. They describe the types of the arguments passed into the
< subroutine at its two different entry points. Where they are in memory,
< if at all, is a function of the compiler, where they are declared in
< the calling program and how they are used when calling the
< subroutine(s).

As far as I know, ENTRY originated in IBM's Fortan IV, much of which
became the Fortran 66 standard. ENTRY was not, though, part of
Fortran 66.

The OS/360 version of Fortran IV used call by value result, often
called copy-in/copy-out, for scalar arguments to subprograms, and
that allowed for some features that would not otherwise work.

In the case of ENTRY (see previous posts for the exact quote),
one was allowed to access dummy arguments from entry points
used in previous calls. It isn't that that x and n have the
same memory location, but that the memory location is preserved
between calls. (A side effect of call by value result.)
Fortran IV originated earlier than S/360, and one should go back
to the 7090 Fortran to see how it was done earlier, but I haven't
done that.

< That I'd accepted that x and n _would_ be the same location was
< premised on my knowledge of some calling conventions and particularly
< how the RSX-11M and VAX/VMS compilers do it. Some compilers may do it
< differently and have some checks that could cause a warning to be
< issued. That doesn't seem to be the case with the original poster's
< compiler though.

The idea of x and n having the same location, EQUIVALENCEd in
Fortran terms, seems strange. That wouldn't allow one to use
values from previous calls. It reminds me, though, that a common
(though I believe not required) implementation of FUNCTION return
values is to equivalence the return variables. You can assign
a value to the variable corresponding to any ENTRY point of
a function, not necessarily the one that was called. That works
correctly if the return type is the same.

< Actually the point I was, unsuccessfully, trying to make was that the
< argument passed to subroutine findxc (n) is likely, and certainly is on
< VMS, to be in Read-Only memory. Any attempt to write to that location,
< on VMS at least, will cause a memory protection/segment fault.

VMS, or at least some versions of VAX/VMS, keep constants in
read-only pages. (A little easier with the VAX 512 byte page,
otherwise considered too small by many people.) That prevents
the accidental modification of constants passed to subprograms,
a Fortran feature for many years.

< The other point that struck me later was that if n were 4 bytes then x
< would be 8 and IF n and x were the same location then it would also be
< possible to for n to writeable but adjacent to read-only code. In all
< cases, I agree 'it is not good practise'.

< As I said in the original, I had just found this self-same problem in a
< piece of code I'd inherited and was modifying to meet a change in
< requirement.

I don't remember that VMS had the IBM pass by value result, but it
is possible. (I believe the VAX/VMS Fortran manual is on bitsavers.)
The IBM explanations and examples involve using the values from
previously called entry points (including the main entry), but not
changing the value. I believe that one can change the value, but
that still seems to require that it have a value from a previous
call. The OP code referenced one that wasn't a dummy argument from
a previous call to the subprogram.

-- glen
From: Richard Maine on 4 Oct 2009 12:26
David Weatherall <nospam(a)nowheren.no.how> wrote:

> Richard Maine wrote:

> > x and n are DIFFERENT variables. There is absolutely nothing that
> > makes them be the same location. No, having the same position in the
> > argument list of two different entries does not do anything at all
> > like that.

> isn't it the case that x and n are different TYPE
> definitions. They describe the types of the arguments passed into the
> subroutine at its two different entry points.

Yes. Sort of. But your exact wording still makes me suspicious that you
don't understand. It is not different types of the same arguments. It is
completely different arguments.

> Where they are in memory,
> if at all, is a function of the compiler, where they are declared in
> the calling program and how they are used when calling the
> subroutine(s).

No, not really. In some struct sense it is true that the standard does
not talk about memory locations and compilers can do all kinds of
strange things with memory as long as they follow the requirements of
the standard. But there are nonetheless things that the standard all but
guarantees or prohibits and that realstically can be said about any
compiler you will ever see.

In this case that includes the fact that this code will not have the
effect that you describe.

> That I'd accepted that x and n _would_ be the same location was
> premised on my knowledge of some calling conventions and particularly
> how the RSX-11M and VAX/VMS compilers do it.

Then I suspect you misunderstand either the code or the calling
conventions. Perhaps it might have been the case in some nonstandard
pre-f77 implementation of entry, but I simply do not believe that the
VAX/VMS f77 compilers would work that way. I can't see how they could do
that and reasonably conform to the standard, which I'm very sure they
do.

Here there is no actual argument ever given for n, so one can't say that
the actual arguments for n and x are the same based on that. I think you
are still thinking of the dummy argument lists as two different
declarations of the same arguments. It isn't that way and can't be that
way. If it were, then the compiler could not reasonably make perfectly
valid code such as

...
entry entry1(n,x)
entry entry2(x,n)
...

work. The lack of ellipses between those two entry statements is
intentional.

> Actually the point I was, unsuccessfully, trying to make was that the
> argument passed to subroutine findxc (n) is likely, and certainly is on
> VMS, to be in Read-Only memory. Any attempt to write to that location,
> on VMS at least, will cause a memory protection/segment fault.

I'm aware of that, but it isn't the same location - not in any f77 or
later code. nonstandard f66 extensions are a different matter.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Steve Lionel on 5 Oct 2009 20:35
Richard Maine wrote:
> David Weatherall <nospam(a)nowheren.no.how> wrote:

>> That I'd accepted that x and n _would_ be the same location was
>> premised on my knowledge of some calling conventions and particularly
>> how the RSX-11M and VAX/VMS compilers do it.
>
> Then I suspect you misunderstand either the code or the calling
> conventions. Perhaps it might have been the case in some nonstandard
> pre-f77 implementation of entry, but I simply do not believe that the
> VAX/VMS f77 compilers would work that way. I can't see how they could do
> that and reasonably conform to the standard, which I'm very sure they
> do.

Here's what I remember from how the VAX/VMS compiler handled ENTRY (I
was a developer on that for more than ten years). The compiler created
an array of pointers for all the dummy arguments in all the entry points
to a procedure (including the subroutine or function). When the code
was entered through one of the entry points, it stored the address of
each actual argument in the corresponding array location and then
referenced through that array whenever it wanted to access a dummy.
That way it did not have to keep track of which entry point was used.

Since that array was statically allocated (at least until recursion was
added as an extension), the routine would appear to "remember" actual
arguments, to some degree, across calls, assuming the array pointer was
still valid. This was absolutely unsupported and didn't always do what
one might expect.

When we developed the DEC Fortran 90 compiler, from a different code
base, a different method was used which did not have any sort of
"memory" of past arguments, and a lot of customers found that their
broken code was now really broken.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran
From: Richard Maine on 5 Oct 2009 20:57
Steve Lionel <steve.lionel(a)intel.invalid> wrote:

> Richard Maine wrote:
> > David Weatherall <nospam(a)nowheren.no.how> wrote:
>
> >> That I'd accepted that x and n _would_ be the same location was
> >> premised on my knowledge of some calling conventions and particularly
> >> how the RSX-11M and VAX/VMS compilers do it.
> >
> > Then I suspect you misunderstand either the code or the calling
> > conventions. Perhaps it might have been the case in some nonstandard
> > pre-f77 implementation of entry, but I simply do not believe that the
> > VAX/VMS f77 compilers would work that way. I can't see how they could do
> > that and reasonably conform to the standard, which I'm very sure they
> > do.
>
> Here's what I remember from how the VAX/VMS compiler handled ENTRY (I
> was a developer on that for more than ten years). The compiler created
> an array of pointers for all the dummy arguments in all the entry points
> to a procedure (including the subroutine or function). When the code
> was entered through one of the entry points, it stored the address of
> each actual argument in the corresponding array location and then
> referenced through that array whenever it wanted to access a dummy.
> That way it did not have to keep track of which entry point was used.

That makes sense to me. (Besides which, I'd trust your memory of it a
lot better than I would trust my own user-based reconstruction of how it
acted, or for that matter someone else's deduction of how they think it
must have been.)

And note that an implementation like this would *NOT* result in the kind
of effective equivalencing that David appears to think would have
happened. The example in question does not illustrate the phenomenon of
"remembering" the same actual argument. I would not surprise me to find
that David was confusing it with that case, but it is not the same
thing. This was an example with two different arguments, n and x, and
expecting them to be effectively equivalenced, apparently because they
were both argument number 1 in their respective entries. (See the code
in the original post). with the above-described implementation, those
two arguments would correspond to different locations in the array of
pointers; thus setting one of them would have no effect on the other.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 5 Oct 2009 23:22
Steve Lionel <steve.lionel(a)intel.invalid> wrote:
(snip, and previous snip, on ENTRY and dummy arguments)

< Here's what I remember from how the VAX/VMS compiler handled ENTRY (I
< was a developer on that for more than ten years). The compiler created
< an array of pointers for all the dummy arguments in all the entry points
< to a procedure (including the subroutine or function). When the code
< was entered through one of the entry points, it stored the address of
< each actual argument in the corresponding array location and then
< referenced through that array whenever it wanted to access a dummy.
< That way it did not have to keep track of which entry point was used.

That makes sense in terms of the OS/360 Fortran requirement that
you don't reference a dummy unless it is or was previously associated
with an actual argument. (I previously quoted the manual.) That may
actually happen for OS/360 arrays. Scalars actually have a local
variable, (again statically allocated).

I always thought that DEC was in competition with IBM, and would
try to include IBM extensions. Well, ENTRY itself was an IBM
extension to Fortran 66, but I would expect them to follow the
IBM extension. I should look to see what IBM did in VS Fortran.

< Since that array was statically allocated (at least until recursion was
< added as an extension), the routine would appear to "remember" actual
< arguments, to some degree, across calls, assuming the array pointer was
< still valid. This was absolutely unsupported and didn't always do what
< one might expect.

Everything was static for OS/360 including the return address.

< When we developed the DEC Fortran 90 compiler, from a different code
< base, a different method was used which did not have any sort of
< "memory" of past arguments, and a lot of customers found that their
< broken code was now really broken.

-- glen
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Passing optional parameters
Next: Renaming module procedures