Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!chaph.usc.edu!alcor.usc.edu!jeenglis
From: jeenglis@alcor.usc.edu (Joe English Muffin)
Newsgroups: comp.lang.misc
Subject: Re: Fortran vs. C for numerical work
Message-ID: <13585@chaph.usc.edu>
Date: 11 Dec 90 04:04:34 GMT
References: <77124@iuvax.cs.indiana.edu> <1990Dec9.040635.12696@actrix.gen.nz> <13552@chaph.usc.edu> <1990Dec10.070017.19821@actrix.gen.nz>
Sender: news@chaph.usc.edu
Organization: USC Co-Ed Naked Depressed Person's Softball League
Lines: 65
Nntp-Posting-Host: alcor.usc.edu

Bruce.Hoult@bbs.actrix.gen.nz writes:

>>>In C or Pascal you could allocate a structure as a global (static) variable,
>>                                                    ^^^^^^^^^^^^^^
>>To allow recursion, the compiler would have to allocate this
>>as 'auto,' in the caller's stack frame.

>I don't think you read the original posting.  The point I was replying to was
>that in FORTRAN the compiler can generate more efficient code because there
>was no need to allow for recursion.  My point was that if you disallow
>recursion then Pascal or C could do virtually as well.

You wouldn't *need* to disallow recursion though (and if
you did, it wouldn't be C anymore.)  Instead of using
a global static for the parameter block, the compiler
could allocate parameter blocks for each called function
in the caller's stack frame.  Most of these could overlap
in many cases, so the space requirements wouldn't be
much higher than for the usual calling scheme.

>Your saying "To allow recursion, the compiler would have to..." is hardly a
>refutation of something which has assumed that recursion *isn't* happening.

It's very difficult for the compiler to determine
that there's no recursion going on.  To use a static
area for the parameter block, the compiler would have to 
be sure that 1) the called function doesn't call
itself, or any other functions which call it, and
2) the compiler will have access to this information
when compiling any other source units which call 
this function.  You could add a compile time switch
or a #pragma directive, but it seems of limited
utility.  Besides, it's just as easy to allocate
the stack frame in the caller's local storage anyway.

>>>the called routine.  The compiler might even be smart enough to use CALLG,
>>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>Probably not.  Since there's always the possibility that the
>>function will be called from somewhere without a prototype in
>>scope, parameter block argument passing wouldn't be a feasible
>>scheme.

>I don't understand this remark.  Could you explain it?

Actually, I was wrong.  Ignore what I said :-) 

There *is* a problem with variadic functions like
_printf_ under calling schemes where the callee
deallocates the stack frame on return, but since the
calling function would "own" the parameter block, it
shouldn't matter how many formal arguments the callee
takes, only the number of actual arguments.  So the
CALLG instruction sequence would work for C functions
after all, unless I'm missing something else...

The question now is: why DOESN'T the VMS C compiler do
this?  (It would probably work pretty well on 680X0
architectures, too; less so on 80*86s and not at all
well on RISC machines.)


--Joe English

  jeenglis@alcor.usc.edu