From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: A vm for native code in guile Date: Mon, 14 Jan 2013 17:10:10 +0800 Organization: HFG Message-ID: <1358154610.23443.151.camel@Renee-desktop.suse> References: <87obnxreq5.fsf@pobox.com> <1358131906.23443.129.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358154642 4927 80.91.229.3 (14 Jan 2013 09:10:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Jan 2013 09:10:42 +0000 (UTC) Cc: guile-devel@gnu.org To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jan 14 10:10:59 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 1Tug4E-0001el-U1 for guile-devel@m.gmane.org; Mon, 14 Jan 2013 10:10:55 +0100 Original-Received: from localhost ([::1]:58858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tug3y-0003Pk-FV for guile-devel@m.gmane.org; Mon, 14 Jan 2013 04:10:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52128) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tug3p-0003PF-Tx for guile-devel@gnu.org; Mon, 14 Jan 2013 04:10:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tug3i-0000yG-0z for guile-devel@gnu.org; Mon, 14 Jan 2013 04:10:29 -0500 Original-Received: from mail-pa0-f51.google.com ([209.85.220.51]:59639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tug3h-0000wh-KH for guile-devel@gnu.org; Mon, 14 Jan 2013 04:10:21 -0500 Original-Received: by mail-pa0-f51.google.com with SMTP id fb11so2110148pad.38 for ; Mon, 14 Jan 2013 01:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:organization:content-type:x-mailer:mime-version :content-transfer-encoding; bh=Q9I6DtirsDM8gCSnt08YsRnqxqiafe4C2DeA6H8dzW0=; b=sNugIrerrE0pR7Gf8Z3ocB7H3RCcFtIsUfDf6IhuPi5hTgoTMZx4N0X1iDt/jS/b3h O1UHMaJ2jVj058SEs7F7lDt+hFTPEka6VPXuhc4tXrtnPWScq62sHLCIOvZcVVIcBcyz H/ZCK6e2xBekss/EObDNXT5h+yL5VplQHLylzKi3f9+nH0fpqu4KsjWeNP0z++m3ghUS e2hzXbrsLvD01M4O+mh2gLvM8xnxZGsTM4mbaqo2HqEsDm47M4vaFw+lQTUpUMMtJQvX j2uPrg+onvTVQOE9IMWcPZ3ORxyXHfd6NhHSfIqzH7GiNte4kpcxMRIgK+ZYdlArOoTD A+Fw== X-Received: by 10.68.234.36 with SMTP id ub4mr254383634pbc.68.1358154615438; Mon, 14 Jan 2013 01:10:15 -0800 (PST) Original-Received: from [147.2.147.112] ([61.14.130.226]) by mx.google.com with ESMTPS id k4sm8408551paz.26.2013.01.14.01.10.12 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 14 Jan 2013 01:10:14 -0800 (PST) In-Reply-To: X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.51 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:15418 Archived-At: On Mon, 2013-01-14 at 09:43 +0100, Stefan Israelsson Tampe wrote: > IMO, we don't have to write assembler again, since GNU Binutils does. > The only necessary work is to map bytecode->asm, and add a AOT option > with a script into 'guild' for calling Binutils. > > > This is my approach: translate each opcode to a either a call to a c > func or > to a few assembller instructions. The translation to the c code is > easy. But jumping and > moving data is best served by native instrucitons. Also we would like > to effectivelly use machine registers > ta gain perhaps an extra 2x in speed. This means quite a lot of work > in assembler to move > data around. To note we can gain some use of gcc by compiling for a > restricted set of registers > in order to be able to have a set of registers free for temporary > storage. All this also means that we > can perhaps restrict the assembler to just include features for a very > small set of instructions meaning that > the assembler writing will not be as huge effort. > Though write an simple x86-specific assembler won't be a difficult one, I recommend reuse GNU code as much as possible. And convert Scheme code to C code could be one of the way. It's nice to give it a try. ;-) > I'm not really sure how to use binutils as you suggest for the whole > setup though. Perhaps you can explain in more detail. > Binutils contains 'Assembler' & 'Linker' and other binary tools to handle the native code generation. I mention it here since we don't have to write assembler, the way I suggest is to generate asm code only, then use binutls to make it an elf one. I think it's easier to implement a lisp-dialect compatible with machine-description of GCC, like this: https://android.googlesource.com/toolchain/gcc/+/57cfd7a03820d1241333e059feda0ab04829f575/gcc-4.6/gcc/config/i386/i386.md And use this dialect to map registerVM-bytecode->asm. Then use 'as' to assemble it. This way could avoid to re-implement assembler, and reuse large of GCC code. > /Stefan > > > On Mon, Jan 14, 2013 at 3:51 AM, Nala Ginrut > wrote: > On Wed, 2012-08-01 at 22:59 +0200, Stefan Israelsson Tampe > wrote: > > 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. > > > > > IMO, we don't have to write assembler again, since GNU > Binutils does. > The only necessary work is to map bytecode->asm, and add a AOT > option > with a script into 'guild' for calling Binutils. > We may borrow some work from GCC. I don't know if it's easy, > but GCC > uses Lisp-like thing to handle machine-description. Though it > could be > interesting, it's a lot of work todo. Then it could support > many > platforms rather than x86. > > > * 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 > > > > >