Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| From: | George Neuner <gneuner2@comcast.net> |
| Newsgroups: | comp.compilers |
| Date: | Tue, 13 Feb 2018 22:37:42 -0500 |
| Organization: | A noiseless patient Spider |
| References: | 18-02-009 18-02-012 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="14853"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | code |
| Posted-Date: | 13 Feb 2018 23:12:05 EST |
On Tue, 13 Feb 2018 00:42:00 -0700, Louis Krupp
<lkrupp@nospam.pssw.com.invalid> wrote:
>On Mon, 12 Feb 2018 11:25:36 -0800 (PST), dror.openu@gmail.com wrote:
>
>>Suppose I have a simple C-like programming language: ...
>>Like you can see, it supports nested functions.
>
>gcc supports nested functions as an extension to C. Compiling this
>program with -O0 -fdump-tree-all and looking at the generated files
>might give you an idea of one way to do it: ...
>The alternative, a display vector, seems like it would be easier to
>implement unless you're doing this for a real machine with a real (and
>therefore limited) set of registers.
The display doesn't need to be in registers [though the pointer to the
display itself should be]. Since every non-leaf function will touch
some part of the display, it will tend to stay in cache close to the
CPU.
And a display doesn't need to be large to be effective. Lexical
definition hierarchies tend to be quite shallow. Studies of nested
functions done back in the days of Pascal showed that 16 entries
sufficed for all but a tiny percentage of code.
Also remember that OO is an orthogonal dimension: the depth of an
object hierarchy will not be limited by using a display.
However if you mix objects and display nested functions, I *think* it
would be necessary to maintain a separate display instance per object
type.
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.