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: native compilers Date: Mon, 21 Jan 2013 19:43:50 +0100 Message-ID: References: <874nia5vgw.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc12729384d704d3d0d703 X-Trace: ger.gmane.org 1358793839 31837 80.91.229.3 (21 Jan 2013 18:43:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Jan 2013 18:43:59 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 21 19:44:17 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 1TxMLu-0003u6-HR for guile-devel@m.gmane.org; Mon, 21 Jan 2013 19:44:14 +0100 Original-Received: from localhost ([::1]:40689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxMLd-0005yS-HC for guile-devel@m.gmane.org; Mon, 21 Jan 2013 13:43:57 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxMLY-0005yB-Pd for guile-devel@gnu.org; Mon, 21 Jan 2013 13:43:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TxMLW-0000VP-U7 for guile-devel@gnu.org; Mon, 21 Jan 2013 13:43:52 -0500 Original-Received: from mail-qc0-f180.google.com ([209.85.216.180]:56427) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxMLW-0000VK-Oa for guile-devel@gnu.org; Mon, 21 Jan 2013 13:43:50 -0500 Original-Received: by mail-qc0-f180.google.com with SMTP id v28so3894743qcm.25 for ; Mon, 21 Jan 2013 10:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HEa1+kzLayLZ5xFyfEIS5oFmr5HeyVi4bb18JifErKQ=; b=EXwFhmww81NTGJ6xqfnsCavuZJ24b0NDm1iq+Li9ITmTAMH+OlpU6ydKlnCOUTjBce J7XsSm+X8uuaP6ySVmkQ7vIEFAbqKxrC7aYqXn8sLF+Q7MrP1zlVvG7+DY9IvYCcSgYS KAB1wM/74qeKfAAIXXvvmAbR5kBSKiatsbBBN5lUJz5EkY+i8QdGOb3j4Eg4kTODJJpi KEeXwl/9YopXewS0ugnGspITZNEssWzgwmcBOfVPgvyq2gboPLU0pzIzjHT8dO9ORi97 npXZ4uj4t61NQ9pD96nx3WC6QIsrao06X+a49TR1GfbkApeccGRyLHPdd1fOaaSKOQGT x0ww== X-Received: by 10.49.74.10 with SMTP id p10mr23045693qev.35.1358793830269; Mon, 21 Jan 2013 10:43:50 -0800 (PST) Original-Received: by 10.49.28.135 with HTTP; Mon, 21 Jan 2013 10:43:50 -0800 (PST) In-Reply-To: <874nia5vgw.fsf@pobox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.216.180 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:15503 Archived-At: --047d7bdc12729384d704d3d0d703 Content-Type: text/plain; charset=ISO-8859-1 Yeah, this is pretty crazy stuff. But crazy fun stuff! 1. Anyway I think that I could just do away with two table lookups to reach both c-function pointers and the goto gosub stuff generated from assembler. 2. A think more work is needed of the extra layer to allow for correct continuation properties. 3. Would be good if we could just pass a pointer to the rtl-vm local data in stead of copying them into a third vm. 4. Good register handling is needed, right now this is the most simplest approach you can have towards native / JIT compiling e.g. take the rtl code and transform it directly to rtl code. you do get faster code but it would be nice to actually take advantage of hardware regiosters. And for that we would need ideally to compile from something else than rtl bytecode. Anyway I could imagine an intrmediate state of guile where we took this simplistic approach to compiling - it should at least be very fast to compile the code and if we look at it as some speedier VM it's actually not a bad idea appart from beeing hard to maintain with respect to hardware architecture. 5. To simplify further we could design most of the meaty stuff in C-code and restrict the target registers for this code and hook everything together with some basic assembler. Then I don't expect the assembler work to be that hefty. 6. As Noha later on in the list point out, there is already JIT engines out there that can work with this without the extra overhead. But I'm so in love with assembler in scheme that I couldn't resist hacking this together. Regards Stefan On Mon, Jan 21, 2013 at 5:53 PM, Andy Wingo wrote: > On Sat 22 Sep 2012 23:28, Stefan Israelsson Tampe > writes: > > > I've now coded two version of native compilers for x86-64 linux > > compiling either the old guile-2.0 VM language or guile-2.2 RTL VM > > language. > > This is pretty crazy and wonderful stuff, Stefan. > > > https://gitorious.org/aschm > > https://gitorious.org/aschm/aschm/blobs/rtl/module/native/vm/inst.scm > looks really promising. > > I guess I need to consolidate the RTL branch now, and we need to make > sure that we can plug in a JIT. I don't want to incorporate all of this > code at once, so ideally we can make it so that you can load your code > as a module and Guile will have the needed hooks to run JITted code if > it is there. > > Excellent hacking! > > Andy > -- > http://wingolog.org/ > --047d7bdc12729384d704d3d0d703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, this is pretty crazy stuff. But crazy fun stuff!
1. Anyway I think that I could just do away with two = table lookups to reach both
c-function pointers and the got= o gosub stuff generated from assembler.

2. A think more work is needed of the extra= layer to allow for correct continuation
properties.
<= div style>
3. Would be good if we could just pass a poi= nter to the rtl-vm local data in stead of copying=A0
them into a third vm.

4. Go= od register handling is needed, right now this is the most simplest approac= h you can have
towards native / JIT compiling e.g. take the= rtl code and transform it directly to rtl code. you do get
faster code but it would be nice to actually take advantage of h= ardware regiosters. And for that
we would need ideally to c= ompile from something else than rtl bytecode. Anyway I could imagine an=A0<= /div>
intrmediate state of guile where we took this simplistic approac= h to compiling - it should at least=A0
be very fast to=A0co= mpile the code and if we look at it as some speedier VM it's actually n= ot a bad idea=A0
appart from beeing hard to maintain with respect to hardware arc= hitecture.

5. To simplify further we c= ould design most of the meaty stuff in C-code and restrict the target regis= ters
for this code and hook everything together with some basic assem= bler. Then I don't expect the assembler
work to be that= hefty.

6. As Noha later on in the lis= t point out, there is already JIT engines out there that can work with this= without the
extra overhead. But I'm so in love with assembler in scheme = that I couldn't resist hacking this together.

Regards
Stefan



On Mon, Jan 2= 1, 2013 at 5:53 PM, Andy Wingo <wingo@pobox.com> wrote:
On Sat 22 Sep 2012 23:28, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wri= tes:

> I've now coded two version of native compilers for x86-64 linux > compiling either the old guile-2.0 VM language or guile-2.2 RTL VM
> language.

This is pretty crazy and wonderful stuff, Stefan.

> https://gito= rious.org/aschm

https://gitorious.org/aschm/aschm/blobs/rtl/module= /native/vm/inst.scm
looks really promising.

I guess I need to consolidate the RTL branch now, and we need to make
sure that we can plug in a JIT. =A0I don't want to incorporate all of t= his
code at once, so ideally we can make it so that you can load your code
as a module and Guile will have the needed hooks to run JITted code if
it is there.

Excellent hacking!

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

--047d7bdc12729384d704d3d0d703--