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: A vm for native code in guile Date: Wed, 1 Aug 2012 22:59:28 +0200 Message-ID: References: <87obnxreq5.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae93412511e5e4804c63a926c X-Trace: dough.gmane.org 1343854776 10641 80.91.229.3 (1 Aug 2012 20:59:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 1 Aug 2012 20:59:36 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Aug 01 22:59:37 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 1Swg12-0003cG-DJ for guile-devel@m.gmane.org; Wed, 01 Aug 2012 22:59:36 +0200 Original-Received: from localhost ([::1]:44368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swg11-0004eF-Rj for guile-devel@m.gmane.org; Wed, 01 Aug 2012 16:59:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swg0z-0004e7-6Q for guile-devel@gnu.org; Wed, 01 Aug 2012 16:59:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swg0w-00021t-Ev for guile-devel@gnu.org; Wed, 01 Aug 2012 16:59:33 -0400 Original-Received: from mail-yw0-f41.google.com ([209.85.213.41]:58551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swg0w-00021l-7U for guile-devel@gnu.org; Wed, 01 Aug 2012 16:59:30 -0400 Original-Received: by yhr47 with SMTP id 47so9090585yhr.0 for ; Wed, 01 Aug 2012 13:59:29 -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=AFRS7gHYQIWIT7pZ1rsiXYzMMQdlNYTLvTwh1fnzDc4=; b=MR8Jk+JlIMAQtPxitITkzq8KpRJTq+kseJTAtj611ppX1kqRxE3SfqB1Hm8QWtJzkN j52eS6etpFxcjnN6gzc8QEd6aiR9fYCKF12DgEYRBl19IrmP2ynKHLDtrTnXS54RHdNb bWMMZfdn7a+qTjk6UaRrcMPjO5LURrZjVdLFuR/0PHc9V8kbFtLWCFwQbFDM8pbo3Gs/ iCuxQ1aOrktFm24V3eL3BtqdMc7zjQfnP2U6cv14gOiESDv1Fuse503AU0FG2BlOVZUL bdiqozIW/O6i64IUvbHNw7/RkoIw6YmfLOGjwN6KK3i61dk00LUw8CjxFjsLa+zYb5qj H0yA== Original-Received: by 10.50.216.202 with SMTP id os10mr5225668igc.17.1343854768709; Wed, 01 Aug 2012 13:59:28 -0700 (PDT) Original-Received: by 10.50.41.196 with HTTP; Wed, 1 Aug 2012 13:59:28 -0700 (PDT) In-Reply-To: <87obnxreq5.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.41 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:14764 Archived-At: --14dae93412511e5e4804c63a926c Content-Type: text/plain; charset=ISO-8859-1 Hi, The byte-code -> native-code compiler is does serve my needs pretty well now. It should really soon be possible to add code that will auto compile bytecode versions to native versions. The compiler is not perfect and some instructions is missing. But it can go from VM->NATIVE->VM and so on so whenever there is missing instruction the compiler can bail out to vm code. What's left is to be able to go from VM to Native returning multiple values and in all call positions. To note * the code is for x86-64, linux. * Windows have another calling convention => the assembler has to be recoded => we need compilers for all interesting combinations of operating systems and native targets * Using the C-stack is nice because the native push and pop instructions can be used as well as brk-ings makes for automatic stack growth? also calling out c functions can be fast. On the other hand stack traces is defunct with this code and I'm uncertain how the prompting will cope with this feature. It's probably better to use a separate stack for the native code and model it like the wip-rtl stack. On the other hand it has been convenient to use it as a stack to save variables before calling out to helper c-functions, but these helper functions usually is on the slow path and the savings can be done using helper registers that is local to the vm a little bit slower but doable. Not sure what path to take here. * Writing assembler is really tough. Because debugging is really difficult. * To ease things I compiled C code and examined the assembler => fragile and difficult to port the code. The final version needs to put more effort into probing for constants used in the generated assembler. * x86 code is pretty different because of the low number of registers and invariant registers over c-call's * prompt and aborts are tricky instructions! Example: as an example reducing a list of 1000 elements with a function that is basically + a 4x increase in performance when compiling to native code could be seen. This are typical figures for what one can expect to improve in speed. A smarter usage of registers and less poping and pushing (RTL) could mean that we can increase the speedup from stable-2.0 even further. I will next week start working on the RTL branch porting the current setup but use the rtl stack in stead of the native C stack. Regards /Stefan --14dae93412511e5e4804c63a926c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The byte-code -> native-code compiler is does serve my needs = pretty well now. It should really
soon be possible to add code that will= auto compile bytecode versions to native versions. The compiler is not per= fect and some instructions is missing. But it can go from VM->NATIVE->= ;VM and so on so whenever there is missing instruction the compiler can bai= l out to vm code. What's left is
to be able to go from VM to Native returning multiple values and in all cal= l positions.

To note

* the code is for x86-64, linux.
* Windows have another calling convention =3D> the assembler has to be = recoded
=A0 =3D> we need compilers for all interesting combinations of operating= systems and native targets

* Using the C-stack is nice because the = native push and pop instructions can be used as well as
=A0 brk-ings mak= es for automatic stack growth? also calling out c functions can be fast. On= the
=A0 other hand stack traces is defunct with this code and I'm uncertain= how the prompting will
=A0 cope with this feature. It's probably better to use a separate stac= k for the native code and model
=A0 it like the wip-rtl stack. On the o= ther hand it has been convenient to use it as a stack to save=A0
=A0 va= riables before calling out to helper c-functions, but these helper function= s usually is on the slow=A0
=A0 path and the savings can be done using helper registers that is local t= o the vm a little bit slower
=A0 but doable. Not sure what path to take= here.

* Writing assembler is really tough. Because debugging is rea= lly difficult.

* To ease things I compiled C code and examined the assembler =3D> f= ragile and difficult to port the
=A0 code. The final version needs to p= ut more effort into probing for constants used in the generated=A0
=A0 = assembler.

* x86 code is pretty different because of the low number of registers a= nd invariant registers over c-call's

* prompt and aborts are tri= cky instructions!

Example:
as an example reducing a list of 1000 = elements with a function that is basically + a 4x increase in performance w= hen compiling to native code could be seen. This are typical figures for wh= at one can expect to improve in speed. A smarter usage of registers and les= s poping and pushing (RTL) could mean that we can increase the speedup from= stable-2.0 even further.


I will next week start working on the RTL branch porting the curren= t setup but use the rtl stack in stead of the native C stack.

Regard= s
/Stefan
--14dae93412511e5e4804c63a926c--