glen herrmannsfeldt

Would anyone like to comment on ENTRY variables referencing
INTERNAL procedures?

There is a discussion in comp.lang.fortran (I am not yet
crossposting) on adding something similar to Fortran 2008.

I know PL/I has done it since the beginning, and I don't know
that it is especially easy, but I don't think it is that hard,
either.

I don't want to get into any flame wars, just constructive
comments on actual implementations.

-- glen

peter flass

I can only comment on my own implementation.
At the time a value is assigne to the variable the entry must ke
"known", which means its static DSA backchain must be active. Both the
address of the entry and the address of the containing DSA are assigned.
When calling the entry variable the compiler only needs to load the DSA
address and call the entry address.

The problem *I* have, and I'd assume that IBM handles this better, is
the case where the entry variable might be passed somewhere up the
chain, for example:

a: PROC RETURNS(ENTRY);
DCL e ENTRY VARIABLE;
e = inner;
return(e);
inner: proc;
end inner;
end a;

returns the address of a procedure ("inner") internal to "a", which is
not valid outside of "a".

My solution is to let the programmer shoot him/herself in the foot if
s/he so desires. A better solution is to have all calls to entry
variables be done thru a library routine that checks to insure the entry
is callable, but this adds a lot of overhead to a simple call.

C doesn't have this problem, because it doesn't allow nested functions,
so any function assigned to their equivalent of an entry variable is
always callable. (C syntax always seems to escape me)

[Reading this over, I see that this is a well-defined situation, and I
could probably generate a compile-time error when a procedure returns
the address of one of its internal procedures. It would require
additional analysis I'm not currently doing.]

glen herrmannsfeldt

(snip on ENTRY variables and INTERNAL procedures)

One suggestion someone made for Fortran is to allow it only where
all variables are static. In the case above, though, it might be
that there aren't any of a's variables that are used in e, which
also seems that it could work. I don't think I understand either
the PL/I version or the proposed Fortran version yet.

thanks,

-- glen

peter flass

That's basically what a LIMITED ENTRY is. When I first read the manual
a couple of years ago, I must have had a brain freeze. It says
something like a LIMITED ENTRY variable can only be assigned non-nested
entry constants. Although it should have been obvious, I couldn't
figure out what they were trying to say by "non-nested." Apparently the
mean external procedures or procedures in packages not "nested" within
other procedures. Therefore they don't access auto data in a containing block.

cg

Personally, I would put this in the category of:
"Just because you can, does not mean you should."
Secondary and, in this case, hidden entries to a component are, IMO,
just asking for trouble. Not implementation trouble, but rather trouble
with maintainability, understandability and manageability.

robin

This is my understanding of ENTRY.

The purpose of ENTRY variables is to permit the calling
of any procedure whose name has been assigned to that
variable.

As such, the requirement is that the particular entry name
must be visible to the calling statement as if the
actual procedure name had been specified in the call
(or function reference).

Thus, a call to an internal procedure would be perfectly legal,
provided (of course) that the procedure name is visible to
the CALL statement (or function reference) according to scope rules.

robin

That's right, according to my understanding.
"e" being a variable, the context of it would be lost
when procedure "a" terminates.

Thus, proc "e" could not be called from outside proc "a".

robin

I think that the suggestion is not a good idea.
When the procedure "a" contains a number of
nested procedures that procedure "e" might call,
such would be done without invoking proc "a".
That would be contrary to the scope rules.


It's the same as trying to call the internal procedure
without ever calling the external procedure.
The internal procedure would not be visible until
the extrernal procedure had been called.

waldek hebisch

The key difficulty is that internal (nested) procedures need access
to variables defined in parent procedure. In practice, it is enough
to have address of parent stack frame -- so one has to pass one
piece of extra information. For normal calls one can just use
a hidden parameter. The question is how to accomodate extra
parameter in ENTRY variable?

One way (used in the F compiler) is to use so called thick pointers:
ENTRY variable consists of two machine words: one contain address of
the machine code entry, the other one address of stack frame (DSA)
of the parent procedure. Calling ENTRY variable loads address of
the parent stack frame into dedicated register (R5).

Another way is to use "trampolines": a small code fragments that
load extra parameter into register and call the real code.
When using trampolines ENTRY variable is just one word, but
one also have to allocate memory for a trampoline. Trampolines
may be allocated on the stack (GNU C does this) or one
can use dynamically allocated memory (typical for Lisp and
similar systems).

Both methods have advantages and disadwantages, but for C
(as a non-standard extension supported by GNU C)
trampolines have a very big advantage: C programmers expect
that function pointer can be stored in any other pointer
variable (non-standard, but common expectation). So, using
thick pointers would double size of all pointers (or break
many programs). Using trampolines means that function
pointers are compatible with all other pointers.

The same argument works for non-C languages if internal ENTRY
variables may be passed to C routines.

--
Waldek Hebisch
hebisch@math.uni.wroc.pl

john w. kennedy

You are describing the Optimizer. The F compiler used a DSA counter,
which allowed positive verification that the DSA was live, but was slower.


--
John W. Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)