From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.devel Subject: inderected rtl instructions Date: Sun, 14 Apr 2013 10:42:59 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1365928984 18542 80.91.229.3 (14 Apr 2013 08:43:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2013 08:43:04 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 14 10:43:08 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1URIWe-0004gP-V8 for guile-devel@m.gmane.org; Sun, 14 Apr 2013 10:43:05 +0200 Original-Received: from localhost ([::1]:32914 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URIWe-0003eP-Kg for guile-devel@m.gmane.org; Sun, 14 Apr 2013 04:43:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URIWb-0003dT-Iy for guile-devel@gnu.org; Sun, 14 Apr 2013 04:43:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URIWa-0007FG-FK for guile-devel@gnu.org; Sun, 14 Apr 2013 04:43:01 -0400 Original-Received: from mail-da0-x229.google.com ([2607:f8b0:400e:c00::229]:49007) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URIWa-0007F8-8n for guile-devel@gnu.org; Sun, 14 Apr 2013 04:43:00 -0400 Original-Received: by mail-da0-f41.google.com with SMTP id w4so1682175dam.0 for ; Sun, 14 Apr 2013 01:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=CBsOX/lgglO0S2UFcexdP3Wr0AKBr5LC6mEIPRJQJFc=; b=o1hm7aXL14RgSC2DY1tlF+MjZD2K47vThx38MYpCWfZVfHvgfE/kvglZOarHLBkucq cgp8Z0l/p5r8O9bLu6Sa2grC9NkjW882G27UIKWIc6EkoGQWRmlJ8WOVPFCrGHmqEnuB nMl0NeZEF5P0fND61U51tyx1vz6sob9a/YTOoioBtwb3max35WuO15vCB3Au2l/a2yBN QydEJXcOF9/mkm7bY6E+uOQdOnOPSaL9PGPPeH/2uLYKlLHEoAzsKEHhPFJuZ3znw/6t txYfk68nvmDB7CdNWJPQATm+XbY42KtKpzDLVhghUcLIp1TfQsP71xWpSd0jC8DzerZg 1b0w== X-Received: by 10.68.254.38 with SMTP id af6mr22935820pbd.157.1365928979329; Sun, 14 Apr 2013 01:42:59 -0700 (PDT) Original-Received: by 10.70.22.5 with HTTP; Sun, 14 Apr 2013 01:42:59 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c00::229 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16240 Archived-At: Hi all, In order to support efficient compilation of generators and accumulators I think that we need to add/change the current rtl format with. 1. named gotos 2. Add the possibility that in a call be able to name a stack object. Rationale: 1) If a generator is inlined in a function we must be able to jump back to the code which issued the abort-to-prompt, if there are multiplies of them it would be really nice to store the abort adress in a local variable and use a named goto. Else rtl is well suited to compile inlined generators and accumulators effeciently. To note is that the ability to evaluate a function call at a specified position is the key for the rtl power and the reason you cannot do this trick in current guile-vm. But 2) In the case where we have generator that is a function object e.g. not inline it's possible to try to let it have it's own stack memory and instruction pointer and use that as a generator. This can work if it was not for the fact that. a) function calls uses an unspecified amount of stack. b) The debug infrastructure cannot handle this complexity. c) plain old continuations need to be able to handle these generators in a sane way. d) the dynwind, fluids etc. stack has to be managed sanely in some way So this looks like a much more complex problem, but from the rtl perspective one would like to when calling a function be able to specify which memory position we would like to put that call on. E.g. currently we specify n in fp[n], but we might want to specify fp as well in the call. Anyway, RTL is exciting in that can deliver good performant generators and acumulators with the current scheme semantics e.g. as wingo pointed out in his blog, we probably don't need to dumb down delimited continuations. WDYT