stack size info

stack size info

[A Soare]

16.7 Byte-Code Function Objects
===============================

STACKSIZE
     The maximum stack size this function needs.

------------------------------

(defun p (n)
  "sum"
  (if (> n 1) (+ n (p (1- n)))
    n))



(byte-compile 'p)
(symbol-function 'p)

#[(n)
  "..."
  [n 1 p]
  3            <=<= here is the stack size.
  "sum"]

But I believe that a recursive function has the stack greater, 3*n, not 3. For every recursion I believe that the stack size get greater with 3, so the stack is dependent of n. Is it true?

Is this a little error of explanation in INFO file?

Re: stack size info

[ttn]

   From: A Soare <alinsoar@voila.fr>
   Date: Tue, 20 Mar 2007 14:22:14 +0100 (CET)

   #[(n)
     "..."
     [n 1 p]
     3            <=<= here is the stack size.
     "sum"]

   But I believe that a recursive function has the stack greater, 3*n,
   not 3. For every recursion I believe that the stack size get greater
   with 3, so the stack is dependent of n. Is it true?

   Is this a little error of explanation in INFO file?

i think the intention of the documentation is that "this function" means
this "this function call".  to me it seems pretty clear, but that may be
due to recent coffee intake...  could you suggest a change to make the
explanation clearer for you?

thi

Re: stack size info

[A Soare]

STACKSIZE
     The maximum stack size this function needs. In case of recursion,
     every recursive call grows function's stack size with this constant.

########

This is a litte better?

It is mecessary to use "maximum". It is not an exact quantity?

Re: stack size info

[David Kastrup]

A Soare <alinsoar@voila.fr> writes:

> STACKSIZE
>      The maximum stack size this function needs. In case of recursion,
>      every recursive call grows function's stack size with this constant.
>
> ########
>
> This is a litte better?

I don't think so.  My guess is "The maximum stack size this function
needs for execution, disregarding further (including recursive)
function calls as those extend the stack on their own."

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: stack size info

[Thien-Thi Nguyen]

   From: David Kastrup <dak@gnu.org>
   Date: Thu, 22 Mar 2007 19:24:10 +0100

   A Soare <alinsoar@voila.fr> writes:

   > STACKSIZE
   >      The maximum stack size this function needs. In case of recursion,
   >      every recursive call grows function's stack size with this constant.
   >
   > ########
   >
   > This is a litte better?

   I don't think so.  My guess is "The maximum stack size this function
   needs for execution, disregarding further (including recursive)
   function calls as those extend the stack on their own."

i'm inclined to leave the docs alone.  the node's entire context is a
single function and thus the STACKSIZE element of the byte-code function
object pertains to a single function call.

however, if pressed, i will suggest:
The maximum stack size this function might need when called.

"might" because it is possible that any particular call uses less than
that amount.  "when called" addresses recursion.

is that wording ok?

thi

Re: stack size info

[A Soare]

>    From: David Kastrup <dak@gnu.org>
>    Date: Thu, 22 Mar 2007 19:24:10 +0100
> 
>    A Soare <alinsoar@voila.fr> writes:
> 
>    > STACKSIZE
>    >      The maximum stack size this function needs. In case of recursion,
>    >      every recursive call grows function's stack size with this constant.
>    >
>    > ########
>    >
>    > This is a litte better?
> 
>    I don't think so.  My guess is "The maximum stack size this function
>    needs for execution, disregarding further (including recursive)
>    function calls as those extend the stack on their own."
> 
> i'm inclined to leave the docs alone.  the node's entire context is a
> single function and thus the STACKSIZE element of the byte-code function
> object pertains to a single function call.

I think this problem is not at all important, but at a first glance one can imagine something wrong.


> 
> however, if pressed, i will suggest:
> The maximum stack size this function might need when called.
> 
> "might" because it is possible that any particular call uses less than
> that amount.  "when called" addresses recursion.
> 

As you wish.



One more important question is "The maximum stack size" or just simply "the stack size". I can not imagine an example in which this STACKSIZE is greater than the actual real size. Can somebody help me with an example, please?

Thanks.

Re: stack size info

[Stefan Monnier]

>    I don't think so.  My guess is "The maximum stack size this function
>    needs for execution, disregarding further (including recursive)
>    function calls as those extend the stack on their own."

> i'm inclined to leave the docs alone.  the node's entire context is a
> single function and thus the STACKSIZE element of the byte-code function
> object pertains to a single function call.

> however, if pressed, i will suggest:
> The maximum stack size this function might need when called.

> "might" because it is possible that any particular call uses less than
> that amount.  "when called" addresses recursion.

Maybe it could be called a "stack frame".
And I'd use the word "upper bound" rather than maximum.
Also I'd use the word "use" rather than "need".


        Stefan

Re: stack size info

[Thien-Thi Nguyen]

   From: A Soare <alinsoar@voila.fr>
   Date: Fri, 23 Mar 2007 16:08:46 +0100 (CET)

   I can not imagine an example in which this STACKSIZE is greater than
   the actual real size. Can somebody help me with an example, please?

following is an example (created in the *scratch* buffer, btw, so
you can try to recreate it for yourself, as well).  the annotations
(comments) on the right were added by hand.

there are two functions and three function calls.  the second and
third calls illustrate how one function might use a different amount
of stack depending on its operating environment (in this case, the
value of its arg OBJECT).  that amount is at most 4, which coincides
(purposefully) with the STACKSIZE element in the byte-code function
object for `maybe'.

to understand in more detail, you will need to understand how each
operation interacts with the stack (if at all).  for more info,
place the cursor after the following form and type `C-x C-e':

  (info "(elisp)Disassembly")

btw, the construct `(or (byte-compile FOO) (symbol-function FOO))'
is because `byte-compile' returns nil if FOO is already compiled.

thi

___________________________________________________

(defun no-op () t)
no-op

(disassemble (or (byte-compile 'no-op)
                 (symbol-function 'no-op))
             (current-buffer))
byte code:
  args: nil                             ; stack usage
0       constant  t                     ; 1
1       return                          ; 0

(defun maybe (object)
  (when object
    (let* ((a 42)
           (b 6))
      (when (= a (+ b (* b b)))
        object))))
maybe

(disassemble (or (byte-compile 'maybe)
                 (symbol-function 'maybe))
             (current-buffer))
byte code:                              ; OBJECT: nil
  args: (object)                        ; stack usage
0       varref    object                ; 1
1       goto-if-nil-else-pop 2          ; (branch taken)
4       constant  42
5       varbind   a
6       constant  6
7       varbind   b
8       varref    a
9       varref    b
10      dup
11      dup
12      mult
13      plus
14      eqlsign
15      goto-if-nil-else-pop 1
18      varref    object
19:1    unbind    2
20:2    return                          ; 0

(disassemble (or (byte-compile 'maybe)
                 (symbol-function 'maybe))
             (current-buffer))
byte code:                              ; OBJECT: 42
  args: (object)                        ; stack usage
0       varref    object                ; 1
1       goto-if-nil-else-pop 2          ; 0 (branch not taken)
4       constant  42                    ; 1
5       varbind   a                     ; 0
6       constant  6                     ; 1
7       varbind   b                     ; 0
8       varref    a                     ; 1
9       varref    b                     ; 2
10      dup                             ; 3
11      dup                             ; 4
12      mult                            ; 3
13      plus                            ; 2
14      eqlsign                         ; 1
15      goto-if-nil-else-pop 1          ; 0 (branch not taken)
18      varref    object                ; 1
19:1    unbind    2
20:2    return                          ; 0

Re: stack size info

[A Soare]

>    I can not imagine an example in which this STACKSIZE is greater than
>    the actual real size. Can somebody help me with an example, please?
> 
> following is an example (created in the *scratch* buffer, btw, so
> you can try to recreate it for yourself, as well).  the annotations
> (comments) on the right were added by hand.
> 
> there are two functions and three function calls.  the second and
> third calls illustrate how one function might use a different amount
> of stack depending on its operating environment (in this case, the
> value of its arg OBJECT).  that amount is at most 4, which coincides
> (purposefully) with the STACKSIZE element in the byte-code function
> object for `maybe'.
> 
> to understand in more detail, you will need to understand how each
> operation interacts with the stack (if at all).  for more info,
> place the cursor after the following form and type `C-x C-e':
> 
>   (info "(elisp)Disassembly")
> 
> btw, the construct `(or (byte-compile FOO) (symbol-function FOO))'
> is because `byte-compile' returns nil if FOO is already compiled.
> 
> thi
> 
> ___________________________________________________
> 
> (defun no-op () t)
> no-op
> 
> (disassemble (or (byte-compile 'no-op)
>                  (symbol-function 'no-op))
>              (current-buffer))
> byte code:
>   args: nil                             ; stack usage
> 0       constant  t                     ; 1
> 1       return                          ; 0
> 
> (defun maybe (object)
>   (when object
>     (let* ((a 42)
>            (b 6))
>       (when (= a (+ b (* b b)))
>         object))))
> maybe
> 
> (disassemble (or (byte-compile 'maybe)
>                  (symbol-function 'maybe))
>              (current-buffer))
> byte code:                              ; OBJECT: nil
>   args: (object)                        ; stack usage
> 0       varref    object                ; 1
> 1       goto-if-nil-else-pop 2          ; (branch taken)
> 4       constant  42
> 5       varbind   a
> 6       constant  6
> 7       varbind   b
> 8       varref    a
> 9       varref    b
> 10      dup
> 11      dup
> 12      mult
> 13      plus
> 14      eqlsign
> 15      goto-if-nil-else-pop 1
> 18      varref    object
> 19:1    unbind    2
> 20:2    return                          ; 0
> 
> (disassemble (or (byte-compile 'maybe)
>                  (symbol-function 'maybe))
>              (current-buffer))
> byte code:                              ; OBJECT: 42
>   args: (object)                        ; stack usage
> 0       varref    object                ; 1
> 1       goto-if-nil-else-pop 2          ; 0 (branch not taken)
> 4       constant  42                    ; 1
> 5       varbind   a                     ; 0
> 6       constant  6                     ; 1
> 7       varbind   b                     ; 0
> 8       varref    a                     ; 1
> 9       varref    b                     ; 2
> 10      dup                             ; 3
> 11      dup                             ; 4
> 12      mult                            ; 3
> 13      plus                            ; 2
> 14      eqlsign                         ; 1
> 15      goto-if-nil-else-pop 1          ; 0 (branch not taken)
> 18      varref    object                ; 1
> 19:1    unbind    2
> 20:2    return                          ; 0
> 
> 
> 




Thank you very much.


Alin Soare.