From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: A different stack discipline Date: Sat, 3 Nov 2018 19:16:47 +0100 Message-ID: References: <20181102191524.GB947@STATENS_laptop> Reply-To: mikael@djurfeldt.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a097710579c6a81b" X-Trace: blaine.gmane.org 1541268946 12145 195.159.176.226 (3 Nov 2018 18:15:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Nov 2018 18:15:46 +0000 (UTC) Cc: guile-devel To: hugo@lysator.liu.se Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Nov 03 19:15:41 2018 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJ0SR-000335-FF for guile-devel@m.gmane.org; Sat, 03 Nov 2018 19:15:39 +0100 Original-Received: from localhost ([::1]:56451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ0UX-00019E-Jf for guile-devel@m.gmane.org; Sat, 03 Nov 2018 14:17:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJ0U3-00017l-UA for guile-devel@gnu.org; Sat, 03 Nov 2018 14:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJ0Tz-0006UZ-BP for guile-devel@gnu.org; Sat, 03 Nov 2018 14:17:19 -0400 Original-Received: from mail-it1-f170.google.com ([209.85.166.170]:39193) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJ0Tt-0006JD-LT for guile-devel@gnu.org; Sat, 03 Nov 2018 14:17:11 -0400 Original-Received: by mail-it1-f170.google.com with SMTP id m15so7407870itl.4 for ; Sat, 03 Nov 2018 11:17:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ylzTyKFYB2bBZETEe7uq928lE5AJmlm0bJ5UsLxkE7M=; b=Hd0tjbrEoSIPdcvBdvxR1VbnuowaolsS/sFC/4zx2DdgROXHwKZ2VhlAW0F57d6Iwv 6x03YS1j3ophapH8l5g4I2b5UHg02tfBtww34qyghQV7+/VvhqiWOo946vCraI/+6zOa LzOBSRlVvk5Q2n8Z/3dsi2+RHI2qlL7pZvKp0kD6jRWcYsnhlSmR4+v+TzhXtf4VfSpv IFp824qbtM0X0Jfu5qmbi3uBAOGAXO4vMaEa50EFYXg5Vh3O15ph+SepeRyq/weSMH3c pfEUnIt7nkzSEoqrEgA4f1uEwOl4/1pKbcuqFfpLAHfeipt29DU0/3rKdfH4wJH4x+Lc LP1Q== X-Gm-Message-State: AGRZ1gJusaiT1ZTZ2XHDrdu3IqjTMOKnTLCk/vQpU04lgklEinTVXwby VzDyCUVM1c5uI/d1k3v1uXDaBEu7UEbiqt0BHDy6lpQx X-Google-Smtp-Source: AJdET5dA07sqGS1YCTOc0IOvL4c2nlJ0y+HAwAcH322ZX/TBbxndXzfT5fzAGKTR65oeRR2F37eg0Auvz0Ysrr/PsEY= X-Received: by 2002:a05:660c:687:: with SMTP id n7mr1570071itk.59.1541269023133; Sat, 03 Nov 2018 11:17:03 -0700 (PDT) In-Reply-To: <20181102191524.GB947@STATENS_laptop> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.166.170 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19714 Archived-At: --000000000000a097710579c6a81b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 3, 2018 at 4:30 PM Hugo H=C3=B6rnquist wr= ote: > The section, as far as I can see, just describes a machine > which pushes continuation instead of the PC counter to the > stack. > > Also, while in theory quite nice it has the problem that > Guile is really slow in restoring continuations, due to the > fact that we have complete C interoperability. > There's some misunderstanding here. The SICP register machine model is not very different from common register machine models. There's just a difference in how to handle subroutine calls. A short example: Let's first write out all operations involved in a call in a conventional register machine: [...] ; The following three micro operations consitute "call foo ()" (sp) <- pc + offset(L1) ; NOTE the external memory access sp <- sp - 1 pc <- pc + offset(foo) L1: [...] foo: [...] ; the following two micro operations constitute "ret" sp <- sp + 1 pc <- (sp) ; NOTE the external memory access Now look at the call in the SICP register machine: [...] continue <- pc + offset(L1) pc <- pc + offset(foo) L1: [...] foo: [...] pc <- continue It is fewer operations and every operation is immediate with no memory access. I *have* cheated since I omit a need to push the continue register onto the stack, but while this is needed at *every* call for the conventional machine, this is only required once at the beginning of a function in the SICP machine *unless* the function has a tail call, in which case we don't need to push anything. So, while one can say that we only "push around the pushes", we make gains for every tal call. --000000000000a097710579c6a81b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 3, 2018 at 4:30 PM Hugo H=C3= =B6rnquist <hugo@lysator.liu.se> wrote:
The section, as far as I can see, just describes a machi= ne
which pushes continuation instead of the PC counter to the
stack.

Also, while in theory quite nice it has the problem that
Guile is really slow in restoring continuations, due to the
fact that we have complete C interoperability.

There's some misunderstanding here. The SICP register machine m= odel is not very different from common register machine models. There's= just a difference in how to handle subroutine calls. A short example:

Let's first write out all operations involved in a= call in a conventional register machine:

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [...]
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ; The following three micro operations consitute &quo= t;call foo ()"
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (s= p) <- pc + offset(L1) ; NOTE the external memory access
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sp <- sp - 1
=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 pc <- pc + offset(foo)
L1: =C2=A0=C2= =A0 [...]
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
foo:=C2= =A0=C2=A0 [...]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; the= following two micro operations constitute "ret"
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sp <- sp + 1
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pc <- (sp) ; NOTE the externa= l memory access

Now look at the call in the SI= CP register machine:

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 [...]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = continue <- pc + offset(L1)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 pc <- pc + offset(foo)
L1:=C2=A0=C2=A0 [...]

foo:=C2=A0 [...]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 pc <- continue

It is fewer operati= ons and every operation is immediate with no memory access. I *have* cheate= d since I omit a need to push the continue register onto the stack, but whi= le this is needed at *every* call for the conventional machine, this is onl= y required once at the beginning of a function in the SICP machine *unless*= the function has a tail call, in which case we don't need to push anyt= hing. So, while one can say that we only "push around the pushes"= , we make gains for every tal call.
--000000000000a097710579c6a81b--