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: A vm for native code in guile Date: Mon, 2 Jul 2012 09:53:43 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae93408b1cfd6cd04c3d418ad X-Trace: dough.gmane.org 1341215639 31997 80.91.229.3 (2 Jul 2012 07:53:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Jul 2012 07:53:59 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jul 02 09:53:57 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 1SlbSF-0005oW-N5 for guile-devel@m.gmane.org; Mon, 02 Jul 2012 09:53:55 +0200 Original-Received: from localhost ([::1]:51313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlbSC-000650-Kx for guile-devel@m.gmane.org; Mon, 02 Jul 2012 03:53:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlbS8-00064f-SB for guile-devel@gnu.org; Mon, 02 Jul 2012 03:53:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlbS6-0002oX-RW for guile-devel@gnu.org; Mon, 02 Jul 2012 03:53:48 -0400 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:63992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlbS6-0002oR-Hi for guile-devel@gnu.org; Mon, 02 Jul 2012 03:53:46 -0400 Original-Received: by obhx4 with SMTP id x4so4261183obh.0 for ; Mon, 02 Jul 2012 00:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wDmjERjym7kZVD4PeQEcyWczNMnh7XRoNViuUU4hQd4=; b=S6EhB8CdYJ2rV2H7n2qy+wzBtngzPNcGcfrNruJZWjX/oGsc2rtoRMHSw7TxC0YdKj QXnqOGMye9Rvn8AutkpGp8JXQwbiWSOMVGdcNZWj34CweLlEKF0XpEq0O3MvI+4xyLhp PVSwSKWDi1sRBbxKphKBOQu+w5jlz1kOru8Ga2u3taN9n8SLr96dQ3CsLPUCn+7K85Tu IMlJFcO5weMwG2NFNWJMc/RLB9hEwh7zuZeyxXokg/felBOFcrtytnE299x8XxB9pP0S O02A0dNU5g9HnI3PCjXb6bo9JZ6yBEISGH0+fNkcVR9ZX3TidPAzgAX1ofOtvJylWRe8 dpTA== Original-Received: by 10.50.213.98 with SMTP id nr2mr4540339igc.71.1341215623599; Mon, 02 Jul 2012 00:53:43 -0700 (PDT) Original-Received: by 10.50.41.196 with HTTP; Mon, 2 Jul 2012 00:53:43 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.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:14682 Archived-At: --14dae93408b1cfd6cd04c3d418ad Content-Type: text/plain; charset=ISO-8859-1 Hi, As Noha said, it's not that difficult to hook native code in. But to have something maintainable and bug less will be a challenge. To mitigate this having all code in scheme could be wise. Anyway I can now compile simple functions to native sequences of machine code but with some tools around it so let me explain the setup. The idea is that To have a set of registers that is not touched, the registers are vm - points to a table with vm specific datastructures like free variables etc. jmp - a pointer to a jump table rbx - neeeded to be maintained because of C conventions. The sellected registers will not be changed during a C call and is therefore not needed to be stored when calling out to C (for x86-64, for x86 you do not have this possibility) The vm contains at the moment, vm-rbx vm-r12 | vm-r14 | Stored registers according to the C convention vm-clo | free variable table vm-obj | object table vm-c | C - function table ret | A return adress The generated instruction could feature 1. Pure machine instructions for fastpaths. 2. The option to jump to a vm instruction like a named goto. Then ret needs to contain a return adress 3. The option to call a C function using the function table So the idea here is to keep some of the vm:ness of the setup in order to keep code complexity low. Also rsp ands tbp are used to match sp and fp in the guile-2.0 VM. The general impression after looking at about 142 instructions are that the bytevectors will be typical 10x larger then the VM bytevectors e.g. there is a good compression ratio by using the VM ops. On the other hand we do save space by not inlining everything. Anyway this is indeed a fun exercise and I see it as a testbed for implementation strategies and as a fun testbed for assemblers in guile. The examples that can be run does not include looping (yet) so it's really not that useful but in a matter of a week I would expect that some loop benchmarks can be done. An example currently look like, (use-modules (native vm init)) (use-modules (native vm jit)) (define (f) (vector 1 2 3 4 5 6)) (jit f) (f) execute native execute native/finish $2 = #(1 2 3 4 5 6) /stefan --14dae93408b1cfd6cd04c3d418ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

As Noha said, it's not that difficult to hook native code in= . But to have something maintainable
and bug less will be a challenge. T= o mitigate this having all code in scheme could be wise.
Anyway I can no= w compile simple functions to native sequences of machine code but with som= e
tools around it so let me explain the setup.

The idea is that To hav= e a set of registers that is not touched, the registers are

vm=A0=A0= -=A0=A0 points to a table with vm specific datastructures like free variab= les etc.
jmp=A0 -=A0=A0 a pointer to a jump table
rbx=A0 -=A0=A0=A0 neeeded to b= e maintained because of C conventions.

The sellected registers will = not be changed during a C call and is therefore not needed to be stored whe= n calling out
to C (for x86-64, for x86 you do not have this possibility)

The vm c= ontains at the moment,
vm-rbx
vm-r12=A0=A0=A0=A0=A0=A0 |
vm-r14=A0= =A0=A0=A0=A0=A0 | Stored registers according to the C convention =A0 =A0
vm-clo=A0=A0=A0=A0=A0=A0 | free variable table

vm-obj=A0=A0=A0=A0=A0=A0 | object table

vm-c=A0=A0=A0=A0=A0=A0= =A0=A0 | C - function table

ret=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | A= return adress

The generated instruction could feature
1. Pure ma= chine instructions for fastpaths.
2. The option to jump to a vm instruct= ion like a named goto. Then ret needs to contain a return adress
3. The option to call a C function using the function table

So the i= dea here is to keep some of the vm:ness of the setup in order to keep code = complexity low.
Also rsp ands tbp are used to match sp and fp in the gu= ile-2.0 VM.

The general impression after looking at about 142 instructions are that= the bytevectors will be typical 10x
larger then the VM bytevectors e.g.= there is a good compression ratio by using the VM ops. On the other hand we do save space by not inlining everything.

Anyway this is indeed a= fun exercise and I see it as a testbed for implementation strategies and a= s a fun testbed
for assemblers in guile. The examples that can be run do= es not include looping (yet) so it's really not that useful but
in a matter of a week I would expect that some loop benchmarks can be done.=

An example currently look like,

(use-modules (native vm init= ))
(use-modules (native vm jit))
(define (f) (vector 1 2 3 4 5 6)) (jit f)
(f)
execute native
execute native/finish
$2 =3D #(1 2 3= 4 5 6)

/stefan




--14dae93408b1cfd6cd04c3d418ad--