From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alin Soare Newsgroups: gmane.emacs.devel Subject: Re: please help concerning specpdl Date: Tue, 14 Dec 2010 23:25:41 +0200 Message-ID: References: <35942.130.55.118.19.1291652550.squirrel@webmail.lanl.gov> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd1012870b0ef04976576ac X-Trace: dough.gmane.org 1292361958 23588 80.91.229.12 (14 Dec 2010 21:25:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Dec 2010 21:25:58 +0000 (UTC) Cc: Emacs Dev To: herring@lanl.gov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 14 22:25:54 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PScNd-0005fq-BR for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2010 22:25:54 +0100 Original-Received: from localhost ([127.0.0.1]:44341 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PScNc-00077k-9p for ged-emacs-devel@m.gmane.org; Tue, 14 Dec 2010 16:25:52 -0500 Original-Received: from [140.186.70.92] (port=47103 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PScNT-00077L-Hy for emacs-devel@gnu.org; Tue, 14 Dec 2010 16:25:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PScNS-0005Ic-I3 for emacs-devel@gnu.org; Tue, 14 Dec 2010 16:25:43 -0500 Original-Received: from mail-yw0-f41.google.com ([209.85.213.41]:53800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PScNS-0005IO-C4 for emacs-devel@gnu.org; Tue, 14 Dec 2010 16:25:42 -0500 Original-Received: by ywj3 with SMTP id 3so768740ywj.0 for ; Tue, 14 Dec 2010 13:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=wu2HkSW46s3d/62c1wROEFFg9XrFzEF8R2krvvyvHhU=; b=AjDSqesuFAjCatk6ing1lrthjhZWm6/hOZXEel7wUGFw/8keD4LA4M/sHh6EYMOegV sBrIiSLrCUiGYGS7tASHwu0hm6Oy4LXouXDBsGUp0P+ufRTrBrJoLrJl7gEzFTNVL3s7 DPE6rClFfwoOHuvwK64spZsXOY9VzM+32ra6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IZQDddXEN9pFmwuXDKtH0LtUqAg8kkolrpsBsjrRN+2Cb2JcyvBmHwJAY2l++lwEVE t3IC+iSJl88dPdgTk/fei5z0XaZVbRTeUU+9KtzB+obbf50xoUGR405Kt/+RvH4AosPB p9JPhMJnHRRfgH9Wppim7BVTNJYBCvZ534Vz4= Original-Received: by 10.151.42.16 with SMTP id u16mr8879649ybj.97.1292361941430; Tue, 14 Dec 2010 13:25:41 -0800 (PST) Original-Received: by 10.229.216.199 with HTTP; Tue, 14 Dec 2010 13:25:41 -0800 (PST) In-Reply-To: <35942.130.55.118.19.1291652550.squirrel@webmail.lanl.gov> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133699 Archived-At: --000e0cd1012870b0ef04976576ac Content-Type: text/plain; charset=UTF-8 > > count = SPECPDL_INDEX (); > > record_unwind_protect > > val = Fprogn (args); > > return unbind_to (count, val); > > > Can you explain me the logic of specpdl please ? > > The specpdl contains information needed to remove variable bindings and > provide other services that are guaranteed even in the case of abnormal > exit. Abnormal exits operate by calling longjmp(3), so there's no > guaranteed chance to perform cleanup in the normal flow of execution. But > the function that calls longjmp(3) (`unwind_to_catch') first peruses the > specpdl and handles its elements appropriately, so the guaranteed > operations happen. The actual unwinding is done by `unbind_to', so if the > body exits normally, we just call that to perform the unwinding operations > without longjmp(3). > I think I understand the analogy with longjmp. It is a stack of Lisp Objects, and this stack is used by C code to protect against errors in lisp interpreter. The variables defined by let are memorized in this stack using SAFE_ALLOCA. Why let-binding-variables are memorized exactly here and not elsewhere ? On the other hand, the macro SAFE_ALLOCA is defined as do{ }while (0) why the do-while is good in this case, and not simply brackets? > So: the count identifies how far to unwind in case of normal exit (in case > of abnormal exit, we'll unwind farther anyway, so we don't need `count'). > The `record_unwind_protect' registers something to do at unwind-time, and > then `unbind_to' performs it unless `unwind_to_catch' does. `val' is > passed to `unbind_to' for GC reasons, I believe. > I see that inside unbind_to, the symbols are unbounded 1 by one. Why the specpdl_ptr is not decremented directly with count ? while (specpdl_ptr != specpdl + count) Probably because unbind_to is called from lisp code by (throw 'symbol value), and specpdl_ptr must decrement 1 by 1 until the 'symbol is dound on the stack ? Apart from (throw ... ), is which other situation unbind_to is called ? I see that GCPROx macros are used to protect the variables of type Lisp Object on the stack of C code (that the compiler creates), not to protect the lisp objects in specpdl. The GCPRO protection is against the algorthm of conservative stack. Am I right ? Sorry, I think I understand something, but I am far from enough. Alin. --000e0cd1012870b0ef04976576ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> count =3D SPECPDL_INDEX ();
> record_unwind_protect
> val =3D Fprogn (args);
> return unbind_to (count, val);

> Can you explain me the logic of specpdl please= ?

The specpdl contains information needed to remove variable bindings a= nd
provide other services that are guaranteed even in the case of abnormal
exit. =C2=A0Abnormal exits operate by calling longjmp(3), so there's no=
guaranteed chance to perform cleanup in the normal flow of execution. =C2= =A0But
the function that calls longjmp(3) (`unwind_to_catch') first peruses th= e
specpdl and handles its elements appropriately, so the guaranteed
operations happen. =C2=A0The actual unwinding is done by `unbind_to', s= o if the
body exits normally, we just call that to perform the unwinding operations<= br> without longjmp(3).

I think I understand the analo= gy with longjmp. It is a stack of Lisp Objects, and this stack is used by C= code to protect against errors in lisp interpreter.

The variables d= efined by let are memorized in this stack using SAFE_ALLOCA.

Why let-binding-variables are memorized exactly here and not elsewhere = ?

On the other hand, the macro SAFE_ALLOCA is defined as

do{ =
}while (0)

why the do-while is good in this case, and not simply= brackets?



So: the count identifies how far to unwind in case of normal exit (in case<= br> of abnormal exit, we'll unwind farther anyway, so we don't need `co= unt').
The `record_unwind_protect' registers something to do at unwind-time, a= nd
then `unbind_to' performs it unless `unwind_to_catch' does. =C2=A0`= val' is
passed to `unbind_to' for GC reasons, I believe.
<= br>I see that inside unbind_to, the symbols are unbounded 1 by one. Why the=
specpdl_ptr is not decremented directly with count ?

while (specpdl_ptr !=3D specpdl + count)

Probably because unbind= _to is called from lisp code by (throw 'symbol value), and specpdl_ptr = must decrement 1 by 1 until the 'symbol is dound on the stack ?

Apart from (throw ... ), is which other situation unbind_to is called ?
=
=C2=A0
I see that GCPROx macros are used to protect the variables of= type Lisp Object on the stack of C code (that the compiler creates), not t= o protect the lisp objects in specpdl. The GCPRO protection is against the = algorthm of conservative stack. Am I right ?


Sorry, I think I understand something, but I am far from enough.

Alin.





--000e0cd1012870b0ef04976576ac--