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: Re: wip-rtl native closure creation Date: Mon, 6 Aug 2012 19:46:34 +0200 Message-ID: References: <87ehnkqsbz.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae93409037ab73d04c69c7515 X-Trace: dough.gmane.org 1344275208 17440 80.91.229.3 (6 Aug 2012 17:46:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Aug 2012 17:46:48 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Aug 06 19:46:48 2012 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 1SyRO8-0006lA-6E for guile-devel@m.gmane.org; Mon, 06 Aug 2012 19:46:44 +0200 Original-Received: from localhost ([::1]:38899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyRO7-0005DX-GP for guile-devel@m.gmane.org; Mon, 06 Aug 2012 13:46:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyRO2-0005DN-4B for guile-devel@gnu.org; Mon, 06 Aug 2012 13:46:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyRO0-0007OJ-Lt for guile-devel@gnu.org; Mon, 06 Aug 2012 13:46:38 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:64550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyRO0-0007NE-G1 for guile-devel@gnu.org; Mon, 06 Aug 2012 13:46:36 -0400 Original-Received: by yenr5 with SMTP id r5so3125061yen.0 for ; Mon, 06 Aug 2012 10:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N7zplHURWrFl/xtHIJV27cbM8V4Se3qR7QM2HziOYmg=; b=gdvwl4dSvOB5+8sINB3oDHfTGXhZHr22rYO3PX69tcGV2qDHb1yXA+wsZ8liBOGEi1 PF9I9PWph66pDzsDlw6nFoNadkfc5lPgnQogU1yD5cr1gEjNDmHrU4DI5zYoOXPkPSZp naNw4bpOHvQ2bz+yC2lgWjMQ0GYOJKMhqkXkSaJQOk35PsnqHxEZpZh4+6NtMwqffzSI kVgNnxcofbgFS6crkUtB103Ywu9CtykU+jJO2ZlCA4jU1SUb7WjmrEeygtcel4hIDV/G i9AJYJLLJCss6SNSm2nPLZvPewW7vg2nYR/IAkRVLHJ1VPzYJMKnknWBzbzNUsjJTfvw hThA== Original-Received: by 10.50.236.65 with SMTP id us1mr3503364igc.17.1344275195016; Mon, 06 Aug 2012 10:46:35 -0700 (PDT) Original-Received: by 10.50.41.196 with HTTP; Mon, 6 Aug 2012 10:46:34 -0700 (PDT) In-Reply-To: <87ehnkqsbz.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.169 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:14782 Archived-At: --14dae93409037ab73d04c69c7515 Content-Type: text/plain; charset=ISO-8859-1 Hi, When code is both VM and native it's nice to be able to have both code blocks as a unit because then we can freely compile a function without needing to do graph analysis. It simply makes the life easier to maintain the two setups. And incrementally compile to native on a per uses base and not in one go very much like JIT ing. Also the overhead on the VM side is low but the native execution will of cause be a little bit slower because of an extra indirection. I don't expect the slowdown to be too bad though. Perhaps we could mark the beginning of a code block in a program as 0 -> the rest of the vector is VM code 1 -> the rest of the vector is Native code addr -> there is native code at the addr indirection Then we can skip the expensive extra inderection for native code when suitable. To note here I assume that picking a[0],a[1] is less expensive then a[0],*a[0]. At some stage we may leave the VM and perhaps enter into a Native only mode. Then we can restructure. /Stefan On Mon, Aug 6, 2012 at 11:32 AM, Andy Wingo wrote: > On Sun 05 Aug 2012 17:19, Stefan Israelsson Tampe > writes: > > > Probably it is best to have the first qword / dword in the code to be > > 0 or the native adress e.g. I propose to add that feature to the > > rtl-branch. > > Good question! Given the different tradeoffs, that seems workable. > Another possibility would be to use a different TC7 for native > procedures. After all, the only calls we need to make cheaply are > native->native and bytecode->bytecode, and the rest can go through a > general dispatch loop (possibly with inline caching). WDYT? (Also note > that RTL words are 32 bits wide, which may or may not be sufficient for > native code pointers.) > > Andy > -- > http://wingolog.org/ > --14dae93409037ab73d04c69c7515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

When code is both VM and native it's nice to be able to have= both code blocks as a unit because then
we can freely compile a functio= n without needing to do graph analysis. It simply makes the life easier to = maintain the two setups. And incrementally compile to native on a per uses = base and not in one go very much like JIT ing. Also the overhead on the VM = side is low but the native execution will of cause be a
little bit slower because of an extra indirection. I don't expect the s= lowdown to be too bad though. Perhaps we could mark the beginning of a code= block in a program as

0=A0=A0=A0=A0 -> the rest of the vector is= VM code=A0=A0=A0=A0=A0
1=A0=A0=A0=A0 -> the rest of the vector is Native code
addr -> the= re is native code at the addr indirection

Then we can skip the expen= sive extra inderection for native code when suitable.
To note here I ass= ume that picking a[0],a[1] is less expensive then a[0],*a[0].

At some stage we may leave the VM and perhaps enter into a Native only = mode. Then we can restructure.

/Stefan

On Mon, Aug 6, 2012 at 11:32 AM, Andy Wingo <wingo@pobox.com> wrote:
On Sun 05 Aug 2012 17:19, = Stefan Israelsson Tampe <stef= an.itampe@gmail.com> writes:

> Probably it is best to have the first qword / dword in the code to be<= br> > 0 or the native adress e.g. I propose to add that feature to the
> rtl-branch.

Good question! =A0Given the different tradeoffs, that seems workable.=
Another possibility would be to use a different TC7 for native
procedures. =A0After all, the only calls we need to make cheaply are
native->native and bytecode->bytecode, and the rest can go through a<= br> general dispatch loop (possibly with inline caching). =A0WDYT? =A0(Also not= e
that RTL words are 32 bits wide, which may or may not be sufficient for
native code pointers.)

Andy
--
http://wingolog.org/=

--14dae93409037ab73d04c69c7515--