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: patching gcc to allow other calling conventions Date: Fri, 15 Jun 2012 20:47:11 +0200 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5396b5078f56804c2873e36 X-Trace: dough.gmane.org 1339786042 31309 80.91.229.3 (15 Jun 2012 18:47:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Jun 2012 18:47:22 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jun 15 20:47:21 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 1SfbYG-0002sW-OG for guile-devel@m.gmane.org; Fri, 15 Jun 2012 20:47:20 +0200 Original-Received: from localhost ([::1]:58894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfbYG-0003Qv-PK for guile-devel@m.gmane.org; Fri, 15 Jun 2012 14:47:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfbYC-0003Qe-Rv for guile-devel@gnu.org; Fri, 15 Jun 2012 14:47:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfbYA-0008I7-HQ for guile-devel@gnu.org; Fri, 15 Jun 2012 14:47:16 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:33354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfbYA-0008Gr-8S for guile-devel@gnu.org; Fri, 15 Jun 2012 14:47:14 -0400 Original-Received: by yenr5 with SMTP id r5so2490218yen.0 for ; Fri, 15 Jun 2012 11:47:11 -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=W3jvhS4hfvzSHScAzFkF4Y3u0+KAYS/BZa2QpuA/nQk=; b=c1cQprJ3HKJXUlb/wYYnTH6OKpT4OnUYJs7AxZUVOR5vVw5hlVDfDeDRZWkD9we8mv XXJ6/KEB+0UTFe6WrUeB4Fr6i2o9dgoiYj4qCrnGOV1jGV/BxqoRX20DJno3B1d9KvtK +dNUnBuR+tN2NMmcjAYxMUFjXwolr2bruMVlliPCX9CKA/WKToOIJVMWFB2OIxwvcyKK Nx9ztmk5UmR6dA+JV8QTl2C+Ilfd6+V/Ttcicpqw78cMU1LgdP373nnl4e1ZGDiKozWN 5f/Rywl9KKNnGbxIKbjrk895tw9tH1iPc//8i0ebHlDjek5TPY1nsFh6cvY4c0PE6ya+ Keqg== Original-Received: by 10.50.197.170 with SMTP id iv10mr3012206igc.17.1339786031330; Fri, 15 Jun 2012 11:47:11 -0700 (PDT) Original-Received: by 10.50.109.166 with HTTP; Fri, 15 Jun 2012 11:47:11 -0700 (PDT) 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:14630 Archived-At: --bcaec5396b5078f56804c2873e36 Content-Type: text/plain; charset=ISO-8859-1 Hi, After poking around with inline assembler I conclude that it's possible to use inline assembler and macrology to implement some kind of other calling convention that s suitable for guile. at -O0. But we want -O3, and then we are sold with this approach. Another option is perhaps to follow the clues in wingo:s link e.g. http://atgreen.github.com/ggx/ And make specific arch with our calling mechansim or perhaps even better extend gcc to allow us to mix c-call convention and guile specific. Anyway currently most of the porting of SBCL assembler for x86-64 is done and with this tool I'm experimenting with a simple JIT engine. You can follow the progress at https://gitorious.org/aschm/aschm Currently I can build code to a byte vector and execute it and now most of the assembler works. My plan is to keep the current byte-code as a on file media and then allow to compile the code to a simple native format (Say a 10-20x increase in size). I plan add a new type of objectcode datastructure where we will run the code in native mode If a new function is evaluated that is not compiled to native it will compile it and use that so that the usual lazyness will be employed. The complications of this method will be very low. It will basically branch off to support code for expensive instructions and try to emit at most say 10 native instructions for every byte opcode. In all not much more then a glorified virtual engine. However I would expect some loops with simple instructions to be as fast as what wingo just posted on the list e.g. A simple loop will do 250-500M turns in a second. My personal view is that improvement of our code base has to be incrementally and that experiments of reasonable size and scope should be done, then we can learn and at some point carve out a step forward. I think this is a doable experiment. I have a question here. I would need to add some code to guile in order to hook in this machine and it would be nice to try that out in a guile branch. Shall I do all this in a local repo or do you want to join. I fell like adding another guile repo in github or gitorious is pushing things a litle and maybe we could start a guile-wipedy-jit branch. The reason I wanted to fork sbcl is that it has assemblers for x86,x86-64,alpha,hppa,sparc,ppc,mips e.g a few targets. It would be nice to know what targets to focus on or if we need to add anyone else to the list! Anyway have fun! /Stefan --bcaec5396b5078f56804c2873e36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

After poking around with inline assembler I conclude that it'= ;s possible to use inline assembler and macrology
to implement some kind= of other calling convention that s suitable for guile. at -O0.

But = we want -O3, and then we are sold with this approach.

Another option is perhaps to follow the clues in wingo:s link e.g.
= =A0
=A0=A0 http://atgreen.gi= thub.com/ggx/

And make specific arch with our calling mechansim = or perhaps even better extend gcc to allow us to mix
c-call convention and guile specific.

Anyway currently most of the p= orting of SBCL assembler for x86-64 is done and with this tool I'm expe= rimenting
with a simple JIT engine.

You can follow the progress a= t https://gitorious.org/aschm= /aschm

Currently I can build code to a byte vector and execute it and now most= of the assembler works.

My plan is to keep the current byte-code as= a on file media and then allow to compile the code to a simple native form= at
(Say a 10-20x increase in size). I plan add a new type of=A0 objectcode dat= astructure where we will run the code in native mode
If a new function i= s evaluated that is not compiled to native it will compile it and use that = so that the usual lazyness will be employed.
The complications of this method will be very low. It will basically branch= off to support code for expensive instructions and try to emit at most say= 10 native instructions for every byte opcode. In all not much more then a = glorified virtual engine. However I would expect some loops with simple ins= tructions to be as fast as what wingo just posted on the list e.g. A simple= loop will do 250-500M turns in a second.

My personal view is that improvement of our code base has to be increme= ntally and that experiments of reasonable size and scope should be
done,= then we can learn and at some point carve out a step forward.

I thi= nk this is a doable experiment. I have a question here. I would need to add= some code to guile in order to hook in this machine and it would
be nice to try that out in a guile branch. Shall I do all this in a local r= epo or do you want to join. I fell like adding another guile repo in github= or gitorious is pushing things a litle and maybe we could start a guile-wi= pedy-jit branch.

The reason I wanted to fork sbcl is that it has assemblers for x86,x86-= 64,alpha,hppa,sparc,ppc,mips e.g a few targets. It would be nice to
kno= w what targets to focus on or if we need to add anyone else to the list!
Anyway have fun!

/Stefan

--bcaec5396b5078f56804c2873e36--