Re: Implementing ENTRY

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Paul Brook wrote:
> > apart from that I cooked up the design and the code myself. My idea is
> > to do the following (from a comment I put in resolve.c, the code
> > requires my previous patch):
>
>
> This isn't a new idea, it's what g77 does ;)

Once you think of master functins and case statements, there aren't much 
alternatives on how to do it, I guess :-)

> >       PROCEDURE p_2 ( args_2 )
>
> 			     ^^ Typo? Should be args?
>
> >          CALL master_p ( 2, args_2=args )
                                      ^^^ the typo's here, should be
			                  args_2 :-)
> >       END PROCEDURE
> >           ...
>
>
> This is somewhat unclear on how we handle multiple (possibly overlapping) 
> arguments. For example:
...
> >   The way we make sure that the arguments end up in the right places
> >   is that we give them keyword names of the form "args_n_i", where n is
> >   as above and i is the position in the argument list of that
> >   respective ENTRY. This means we have to generate code to copy the
> >   arguments into the right local variables inside the master function.
>
>
> Maybe that's is what is what you mean here.  IMHO the best way to implement my 

I do.

> example would be:
>
> subroutine _internal_foo (_which, a, b, c)
>   integer which, a
>   integer, maybe_optional :: b, c
>   select case (_which)
>   case (0): goto _label_0
>   case (1): goto _label_1
>   end case
>   call abort
> _label_0:
>   print *, b
> _label_1:
>   if (a .gt. 0) print *, c
> end subroutine
>
> subroutine foo (a, b)
>   integer a, b
>   call _internal_foo (which=1, a=a, b=b)
> end subroutine
>
> subroutine bar (a, c)
>   integer a
>   real c
>   call _internal_foo (which=2, a=a, c=c)
> end subroutine
>
> Either way the example should cover how this is handled.

Originally I thought this would be more difficult to implement than my 
'sets of arguments'-idea, but thinking more about it, I think you're 
right. This way I won't need to setup code to copy stuff around, and I 
don't have to make different parts of the implementation agree on how 
those lists are setup.

> The split between frontend and backend seems sensible. Don't jump through 
> hoops to enforce this though.

That was the outcome of a moment's reflection. If I can do it more 
easily in a different way, I'll do it differently.

> I think "stub" or "thunk" may be more appropriate wording than "trampoline".

:-) I thought about the tailcall conversion, which would convert the 
calls in the 'trampolines' to jumps, where program execution would just 
bounce off into the huge function.

> It looks like that ENTRY statements are redundant. Do we really need them?
> The backend doesn't need to know where the entry points are, so maybe these 
> would be better as a list of interfaces hung off the master symbol

My idea was that the compiler would generate a trampoline whenever it 
encounters an ENTRY in the PROCEDURE's codestream. Admittedly, it might 
be easier to generate these functions as long one is still outside the 
function, I don't know GCC's interna well enough to judge this. Even 
then, having the ENTRYs in the debug output makes it easier to spot 
errors, and amending case EXEC_CONTINUE with case EXEC_ENTRY in the 
translation passes doesn't seem like a huge loss.

> > A thing I haven't yet thought through is the 
> > handling of the RESULT of a function, I hope this will drop easily into
> > this framework.
>
>
> My suggestion would be to create an equivalence of all the result variables.

That's what I thought. It's reassuring that you think that this is the 
only difficulty.

Thanks for looking at this, I think I'll be able to finish a working 
prototype today.

- Tobi