From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Fri, 27 Dec 2019 21:02:50 +0000 Message-ID: References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="25730"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 27 22:05:30 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ikwnZ-0006X5-2a for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 22:05:29 +0100 Original-Received: from localhost ([::1]:38814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikwnX-0004XP-SE for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 16:05:27 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50911) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikwl7-0003pF-PS for emacs-devel@gnu.org; Fri, 27 Dec 2019 16:03:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ikwl6-00019a-GN for emacs-devel@gnu.org; Fri, 27 Dec 2019 16:02:57 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:56406) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ikwl6-00018I-9O; Fri, 27 Dec 2019 16:02:56 -0500 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id xBRL2pQ4029339 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Fri, 27 Dec 2019 21:02:51 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id xBRL2og7007733; Fri, 27 Dec 2019 21:02:50 GMT X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:243715 Archived-At: Stefan Monnier writes: > - Beside the issue of portability/availability of libgccjit, there's > also the issue of stability of libgccjit. More specifically, what is > the probability that libgccjit will still exist more or less in the > same form in 10 or 20 years? So far GCC's main entry point has been > the command line, so we can expect that running `gcc` will still > work 20 years from now. Similarly, LLVM's main entry point is > an API that builds a kind of CFG representation of code, so we can > expect that to still exist 20 years from now. But to the extent that > libgccjit is not very widely used, there's a risk it will completely > disappear or change radically, especially since we use it here in > a way contrary to what its name ("...jit") suggests. Libgccjit is modeled following a C-like semantic, I guess because plugs where a conventional Gcc front-end would. Consequently I've no reason to think this should change but yes... this is not a strong proof I get it. Probably this is more relevant: https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html When a new entry point is added this is always just and additive change to the API. At least this is the policy I understand and follow if I work into it. > a way contrary to what its name ("...jit") suggests. That's an interesting point. I think the only two differences from the "typical" jit use to the one we do are: - We never leak pointers as immediate into the generated code. - We do not ask libgccjit to perform the library load cause we do it with our machinery. And this let me think to Eli's point on windows missing compatibility. There's good chance that the reason for this is that libgccjit does use dlopen&friends. Actually these are exactly the features of libgccjit infrastructure we do *not* use. I've decided to use libgccjit cause I thought was the nicest technical solution. (admittedly quite GNUish :) One could potentially write another final-pass targeting C from LIMPLE. Thanks for the feedback. Andrea -- akrl@sdf.org