| Related articles |
|---|
| From: | Hans-Peter Diettrich <DrDiettrich1@netscape.net> |
| Newsgroups: | comp.compilers |
| Date: | Tue, 13 Feb 2018 12:10:13 +0100 |
| Organization: | Compilers Central |
| References: | 18-02-009 18-02-010 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="85641"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | code |
| Posted-Date: | 13 Feb 2018 11:15:23 EST |
Am 12.02.2018 um 23:16 schrieb dror.openu@gmail.com:
>> [This at least used to be a standard topic in compiler texts. You should
>> be able to do either in O(1). -John]
>
> I'm not sure how to calculate it in compile time, because the call frame
> doesn't have a fixed size, because I'm using the same stack for storing the
> call-frames and for the operations evaluation (iadd, isub, etc..). Maybe I
> should split it into two stacks, one for the call frames, and the second for
> the operation evaluations. I just sharing my thoughts.
>
> [I would think that your compiler should always know how many partial
> results are on the stack above the call frame so it should be able to
> use a fixed offset to get to the chain pointers at the base of call
> frame. -John]
ACK
Simple compilers use a dedicated base pointer register (x86: eBP) for
their stack frame, but clever compilers will track the current stack
pointer offset to that base address.
The calling frames can have a variable size, when the local function is
called from various places in the code. I.e. the address of a local
variable in an outer scope can vary, fixed is only the variable's offset
to its own frame start. That's why the chain of all intermediate frame
pointers must be followed, until the frame of the variable of interest
is found.
Things can become worse if one of the calling functions is called
recursively, so that a variable number of frames has to be traversed
until the outmost frame is found.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.