Xref: utzoo comp.unix.questions:30159 comp.unix.internals:2505 comp.unix.programmer:1524 comp.lang.c:38035
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers
From: kers@hplb.hpl.hp.com (Chris Dollin)
Newsgroups: comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.lang.c
Subject: Re: Unix Stack Frame Questions
Message-ID: <KERS.91Apr8095747@cdollin.hpl.hp.com>
Date: 8 Apr 91 08:57:47 GMT
References: <125@epic.epic.com> <GOEHRING.91Mar25113709@gnu.ai.mit.edu> <3465@unisoft.UUCP> <19157@rpp386.cactus.org> <3035@cirrusl.UUCP>
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Distribution: na
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 18
In-Reply-To: dhesi%cirrusl@oliveb.ATC.olivetti.com's message of 4 Apr 91 19:20:49 GMT
Nntp-Posting-Host: cdollin.hpl.hp.com


Rahul Dhesi says:
   >>But a stack frame seems to be the most efficient way of dealing with
   >>calls and returns.
   >No, there are =many= better ways.
   BZZZZZZZZZZZZZZZZZZ....
   A "stack frame" is the ONLY way of dealing with calls and returns *if
   they may be recursive*.
   *Where* the stack frame lies is another question.  Part of it may be in
   registers.  It's still a stack frame.

Does calling it a stack frame make it a stack frame? It might be just a record
in the heap. Whether we call that a ``stack frame'' or not seems to be a matter
of taste.
--

Regards, Kers 24059 | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."