🚀 go-pugleaf

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
[snip: other attributions]
>|> > Paul Long (plong@perf.com) wrote:
>|> > |> Although there are C-like languages that support nested functions, e.g.,
>|> > |> Gnu C, I've recently learned that the execution model must change to 
>|> > |> support them. Not a pretty sight.
[snip: other quotes]
>Since I started this thread...
>
>I guess it depends on what you consider the execution model.  I always
>thought of things like sequence points made up the execution model.
>As far as I know, the C execution model, as defined in 9899, doesn't
>even have a stack and stack frames, so any changes regarding how such
>are managed could not affect the execution model as presented in the
>standard.  (They would certainly have an effect on the generated
>code.)

I don't believe that the Standard uses the term, "execution model."
There is "execution environment," but not "model." I was using
"model" loosely, I suppose, to describe the rationalized, minimum
implementation requirements to execute a C program.

>BTW: I though the usual solution for the problem of accessing the
>parent function's variables was trampolines, and not an extra
>parameter?  This *is* important in a C implementation in order to
>implement function pointers that have no extra overhead in the case
>where nested functions are not used.

I don't think that this is the usual solution. The Dragon book
describes a couple of other solutions, access links and displays,
which, I believe, are more common.

>And of course, a good compiler may often be able to determine that the
>trampoline is not needed anyway.

Correct.

>Also: the C++ committee considered and rejected nested functions.  I
>believe that at least part of the reason for the rejection was that
>there exist (or might exist) architectures on which trampolines cannot
>be implemented, and in this case, function pointers become more
>complex, which violates the ``you only pay for what you use''
>principle.

Nested functions have also been proposed to the C committee, but I am
certain that it will be rejected.

The problem with trampolines, at least the way thay are typically
implemented, is that it assumes that data and code share the same
address space--that one can execute code in the data space, i.e.,
on the stack. I've written compilers for processors where the code
and data space are separate and this method could not be used. The
alternative solution with trampolines in this situation is to
implement a "stack" in code space. Yucko.

For further reading, FTP a paper from maya.idiap.ch as the file,
pub/tmb/usenix88-lexic.ps.Z. It describes the method, trampolines,
that Gnu C/C++ apparently uses for nested functions.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.