Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!ucsdhub!jack!man!crash!jeh
From: jeh@crash.CTS.COM (Jamie Hanrahan)
Newsgroups: comp.os.vms
Subject: Re: Help Request
Message-ID: <1382@crash.CTS.COM>
Date: Mon, 13-Jul-87 15:25:08 EDT
Article-I.D.: crash.1382
Posted: Mon Jul 13 15:25:08 1987
Date-Received: Wed, 15-Jul-87 02:28:46 EDT
References: <8707110230.AA28524@ucbvax.Berkeley.EDU> <1368@crash.CTS.COM>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Distribution: world
Organization: Crash TS, El Cajon, CA
Lines: 38
Keywords: Fortran ENTRY %LOC
Summary: More on ENTRY statement

In a private communication, Jerry Leichter writes: 
>     [In response to a comment of mine on the lack of any certain way of
>     determining the address of the END of a FORTRAN function, Mr. Hanrahan
>     writes:  ]
> >     VAX-11 FORTRAN supports the ENTRY statement ... Thus, you can ...
> >     
> >     	INTEGER*4 FUNCTION LOCKED_FUNC (ARG, ...)
> >     	-
> >     	-
> >     	(declarations, code, etc.)
> >     	-
> >     	-
> >     	ENTRY LOCKED_FUNC_END (ARG, ...)
> >     	END
> >     
> >     ... [and] use %LOC(LOCKED_FUNC) and %LOC(LOCKED_FUNC_END) to get the
> >     addresses of the beginning and end of the procedure.
> 
> Again, this will PROBABLY work, but there is NOTHING in any FORTRAN definition
> I know of that specifies where the code generated for an ENTRY statement will
> actually be placed.  The fact that control will enter the function just after
> the entry statement is irrelevant - the compiler can allocate the actual entry
> code anywhere it likes, then provide a branch to the appropriate point within
> the function. ...

Hot damn, he's right!  The trick of using %LOC on an ENTRY name came
from the DEC Ed. Svcs. handout for the "Programming VMS in VAX-11 Fortran/
Macro", ca. 1980... and I've never seen it fail... but I don't recall 
seeing anything in the "official" VAX Fortran doc. that guarantees 
ordering of ENTRY points.  

Well, here's a trick that will work:  Put the function to be locked in
a source file by itself.  Put another dummy function in another source
file.  Compile them independently to produce two separate object files.
Then use the Linker CLUSTER options command to specify the order in
which to read the two files.  

Sigh!