From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp JIT Compiler Date: Tue, 14 Aug 2018 13:11:04 -0700 Message-ID: <701cd05f423e0c46595a3010f45414d0.squirrel@dancol.org> References: <87va8ej4o1.fsf@tromey.com> <87mutpiyz6.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1534277403 21983 195.159.176.226 (14 Aug 2018 20:10:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Aug 2018 20:10:03 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Paul Eggert , Tom Tromey , emacs-devel@gnu.org To: "Tom Tromey" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 14 22:09:58 2018 Return-path: Envelope-to: ged-emacs-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 1fpfde-0005bz-Eg for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 22:09:58 +0200 Original-Received: from localhost ([::1]:46186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpffk-0002DX-QM for ged-emacs-devel@m.gmane.org; Tue, 14 Aug 2018 16:12:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fpff4-0002BZ-UW for emacs-devel@gnu.org; Tue, 14 Aug 2018 16:11:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fpff1-00047x-9Z for emacs-devel@gnu.org; Tue, 14 Aug 2018 16:11:25 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36056) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fpff0-00043Y-GC for emacs-devel@gnu.org; Tue, 14 Aug 2018 16:11:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=WcN1qtzy9OsM5dmvfnLRrpcUvkLouhWsfKqbGBYiBIA=; b=XP4MVS1Lfzm5r5BAOvLTfo8YTYQmkxF1DNKArUBG/Kzest8weIZ5JF2TOwdLYWs1D5ms1yegvk+khZeAVgRktQ1HTDdvNYjca1/Q5pbfcQOYZfIlmahWarBnMvo8+EtVFY6SO8zFB6gGDF8VFrVorRQquJXhp/EjtX3+vA5jhZEfLmcTx2R7RADxmK0ffqLP1FYL+yLsw7Jgbh/bWYFUrm0yEeFRaTGOQwbsWxYFU4CaLIScllqMIjhqroahP5EAC/Hhmq3bJHinUXW8A4OMvcL+b9HfSlmf6u7NiW56+kVZACs2vD3CJ/jFG4OSel109TzlI5xTMHGNnj1XohotRQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fpfeh-0004e7-Up; Tue, 14 Aug 2018 13:11:04 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 14 Aug 2018 13:11:04 -0700 In-Reply-To: <87mutpiyz6.fsf@tromey.com> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228536 Archived-At: > Paul> This sounds very interesting. I assume you'd publish it first on a > Paul> branch so that we could look at it? > > Now it is feature/libjit. > > Paul> libjit has only one committer, Aleksey, and no commits since March. > Is > Paul> there a bottleneck there? > > Another possibility is to switch to gcc-jit. On the up side, it is part > of GCC, so it is maintained and widely ported. The down side is that, > currently, it requires more capabilities at runtime; for example it > invokes the assembler and, I believe, uses dlopen under the hood. I still think that needing binutils for ordinary use is a non-starter. > > One thing I've been thinking about with gcc-jit is that it would be > "relatively" straightforward to also have it work as an ahead-of-time > compiler. What I picture here is a step during dumping where all the > dumped bytecode functions are compiled into a shared library. > > It might be worth doing the experiment to find out. In the end, it might be useful to adopt an SBCL-like compiled-code-only model.