|
 |
On 6/30/2011 0:54, Lars R. wrote:
> On 06/29/11 18:49, Darren New wrote:
>> On 6/29/2011 0:44, Lars R. wrote:
>>> I'd suggest something like “A recursion depth of at least 5 m
ust be
>>> supported by the platform. The actual limit might be higher and can b
e
>>> determined by ...”
>>
>> Well, it's not even *recursion* depth, but just call stack depth.
>
> If a language allows recursion you need some kind of stack. If a
> language only allows non-recursive function calls you can hold the loca
l
> variables at fix addresses, as you also wrote below.
Sure. I was just saying that supporting a call stack depth of at least fi
ve
is more precise than supporting a recursion depth of at least five. I.e.,
it's possible to run out of stack space even if there's no recursion
involved, assuming you're allocating locals on a stack.
And it's possible for each function to have its own stack, so it can get
really messy.
>> I think you could require a minimum amount of stack space to be
>> available, if you wanted.
>
> If you require that (non-recursive) function calls use a "stack" at all
.
> That's why both the C and C++ standards avoid to use the term "stack" i
n
> this context.
Right. But you could still phrase it as requiring a minimum amount of spa
ce
for arguments and auto variables. I.e., you could express it as adding u
p
the value of sizeof() for each argument in the call chain and each auto
local in the call chain and have a minimum number there. That doesn't mea
n
you can't implement it differently, but it does give some guarantees abou
t
how much space you have to provide for user variables.
> Sounds better. So it doesn't matter whether parameters are passed on
> some kind of "stack" (in memory or CPU registers) or on fixed locations
> (im memory or fixed CPU registers).
Exactly. It has to be written in terms of the semantics of the language,
not
in terms of an implementation.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
