From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Native code generation and gcc Date: Mon, 05 Dec 2016 17:18:43 +0100 Message-ID: <878truxsbg.fsf@fimbulvetr.bsc.es> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480955146 25612 195.159.176.226 (5 Dec 2016 16:25:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Dec 2016 16:25:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-devel To: Mikael Djurfeldt Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Dec 05 17:25:42 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDw5E-0006AU-IR for guile-devel@m.gmane.org; Mon, 05 Dec 2016 17:25:40 +0100 Original-Received: from localhost ([::1]:42927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDw5I-0005do-F4 for guile-devel@m.gmane.org; Mon, 05 Dec 2016 11:25:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDw41-0004wy-Dr for guile-devel@gnu.org; Mon, 05 Dec 2016 11:24:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDw3y-0006sG-6n for guile-devel@gnu.org; Mon, 05 Dec 2016 11:24:25 -0500 Original-Received: from roura.ac.upc.es ([147.83.33.10]:39845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDw3x-0006rv-QK for guile-devel@gnu.org; Mon, 05 Dec 2016 11:24:22 -0500 Original-Received: from gw-2.ac.upc.es (gw-2.ac.upc.es [147.83.30.8]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id uB5GIiUm017171; Mon, 5 Dec 2016 17:18:44 +0100 Original-Received: from localhost (unknown [84.88.51.85]) by gw-2.ac.upc.es (Postfix) with ESMTPSA id 08F57339; Mon, 5 Dec 2016 17:18:44 +0100 (CET) Mail-Followup-To: Mikael Djurfeldt , guile-devel In-Reply-To: (Mikael Djurfeldt's message of "Sat, 3 Dec 2016 15:52:12 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 147.83.33.10 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:18775 Archived-At: Mikael Djurfeldt writes: > [I apologize beforehand for being completely out of context.] > Are there fundamental reasons for not re-using the gcc backends for native code generation? I'm thinking of the (im?)possibility to convert the cps to some of the intermediate languages of gcc. > If it wouldn't cause bad constraints the obvious gain is the many targets (for free), the gcc optimizations, not having to maintain backends and free future development. > Of course, there's the practical problem that gcc needs to be adapted for this kind of use---but shouldn't it be adapted that way anyway? :) > Just an (old) idea... > Mikael Guile 2.1 has a register-base bytecode VM that makes using a code generation library like GNU lightning [1] a convenient alternative. In fact, that's the library used by nash [2] (an experimental Guile VM that generates native code for hot routines). You also have the experimental GCC JIT interface [3] to achieve similar goals (available upstream since GCC 5, I think). IMO, if guile wants to go the tracing JIT way (like nash), it should store the CPS representation of routines to be able to iteratively apply more heavy-weight optimizations as the routine becomes hotter (called more frequently). For example, you could start with the current state. If the routine is called many times with the same argument types, you can create a version specialized for these types, opening more unboxing possibilities (the routine entry point would then have to be a version dispatcher). If a routine version later becomes hotter, re-compile that version into native code. One open question is whether the VM needs to be changed to count routine "hotness" efficiently (as in nash), or if a simple routine prelude inserted by guile's compiler tower could do that almost as efficiently (the bytecode ISA might need new atomic integer operations to cope with routine tracing in a multi-threaded app). Also, these all are no small tasks. [1] https://www.gnu.org/software/lightning/ [2] https://github.com/8c6794b6/guile-tjit [3] https://gcc.gnu.org/wiki/JIT Cheers, Lluis