🚀 go-pugleaf

In article <446ss1$deg@news0.rain.rg.net> Paul Long <plong@perf.com>
writes:

|> 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.

Yes.  I was thinking of the definition and use of the term in the C++
standard.

|> >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.

It's certainly not the only solution.  Since I'm not currently
involved in compiler development, my contact with implementations is
limited to those publicly available, to whit: GNU.

I know that when I was working on compilers (and the Dragon book had
just appeared), we used displays.  But that was ten years ago; I
simply supposed that things had evolved since then.

|> >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.

Presumably for the same reasons.

|> 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.

During the discussions in the C++ committee, it was pointed out that
it was not necessary that code and data share the same address space,
*IF* there was some way of mapping the distinct address spaces to the
same physical addresses.

Somehow, I don't think I'd particularly enjoy maintaining code which
used such tricks, however.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung