Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: Execute instructions, Bit Blit, Self-modifying code, Programming in Assembler
Message-ID: <6412@aw.sei.cmu.edu>
Date: 28 Jul 88 12:27:48 GMT
References: <787@amethyst.ma.arizona.edu> <4235@saturn.ucsc.edu> <681@auvax.UUCP> <26195@oliveb.olivetti.com> <3435@polya.Stanford.EDU>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (Robert Firth)
Distribution: na
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 25

In article <3435@polya.Stanford.EDU> max@polya.Stanford.EDU (Max Hailperin) writes:

>The rational for passing a closure as the address of a
>(run-time-generated) piece of code is that the compiler can figure out
>that most closures don't really need to be closures.  This is because
>most procedures use only their own local variables and truly global
>variables, but nothing from intermediate levels.  Thus it is desirable
>to have procedures that take procedural parameters work whether passed
>a closure or a non-closed procedure.  The method Chase describes
>allows for this, and thus improves performance in the common case.

Could someone please be so kind as to run the code sample by me again,
if possible with annotations about performance, since I'm afraid I
still don't see it.

The cost of passing the environment pointer to a parametric procedure
is rarely more than one instruction.  I grant you this is wasted if
the procedure being called doesn't need it, but surely there is a
minimum overhead of one instruction in getting from the runtime-
generated code back to the "real" code of the called procedure?

And, of course, when you generate the actual procedure parameter you
don't need to evaluate its environment pointer if you can see it won't
need one; likewise the entry sequence of a procedure can ignore any
passed-in evvironment pointer.