From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Fri, 27 Dec 2019 11:12:33 +0200 Message-ID: <83sgl6p1xa.fsf@gnu.org> References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="4203"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 27 10:13:16 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 1iklgK-0000y6-6C for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 10:13:16 +0100 Original-Received: from localhost ([::1]:60998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iklgI-0005fM-RB for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 04:13:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58629) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iklfh-0004lU-Pr for emacs-devel@gnu.org; Fri, 27 Dec 2019 04:12:38 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iklfh-0003Sb-IY; Fri, 27 Dec 2019 04:12:37 -0500 Original-Received: from [176.228.60.248] (port=4276 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iklfg-0001ca-Af; Fri, 27 Dec 2019 04:12:36 -0500 In-reply-to: (message from Andrea Corallo on Thu, 26 Dec 2019 22:10:56 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:243692 Archived-At: > From: Andrea Corallo > Cc: emacs-devel@gnu.org > Date: Thu, 26 Dec 2019 22:10:56 +0000 > > What do think about the general idea of having a compiler able to native > compile elisp? I don't feel I know enough about programming language theory to give a useful technical opinion. I can only try to play a devil's advocate, and mention a few potential issues with such an approach: . it will need a compiler (and GCC at that) on the end-user system . the code it creates must be used on the same system, or on systems of very similar architecture, so it will be harder to distribute; e.g., release tarballs will be unable to include such code, like we do now with *.elc files . I wonder how you solve the problem with dependency on libgcc and its likes? this could be another source of reduced portability > What do you think about the proposed design (Lisp -> LAP -> LIMPLE -> > libgccjit -> elf)? Again, I have nothing intelligent to say about the technical aspects and validity of this approach, only about its practical implications. This means it's GCC-specific, and moreover requires native support for loading ELF objects, right? Which means it will probably run well only on GNU/Linux and maybe the *BSD systems. That's a bummer for me personally, because my main development machine runs (gasp!) MS-Windows. IOW, I will never be able to run or debug this feature, except by remote login to a GNU/Linux system or some other equally inconvenient method, because neither ELF loading nor libgccjit are available on my system. (Or maybe you intend to make both happen on MS-Windows as part of your work? ;-) > Do you see any weakness in some part of the design you would be > particularly worried about? See above. I also wonder about the debugging. If this feature goes prime time, at first I imagine we will need to debug problems with generated code quite a lot. And since Lisp code frequently calls back into C, we'd need a good way of debugging them both, and being able to relate the generated code to the original Lisp while at that. If this is not possible, or hard to accomplish, and will require people to step through generated code on the machine language level and correlate it with Lisp in their heads, it would mean only a handful of people will be able to solve any such problems. A typical situation is that Emacs segfaults, and the immediate crash locus is a bunch of machine instructions -- how would one go about debugging this? (A similar issue exists with debugging faulty bytecode, but since the byte compiler is very old and mature, this almost never is of any practical importance.) > Do you see in this a potential for having it up-stream in the future? Yes, assuming you (and any others who would like to actively work on that branch) will have enough energy and motivation to bring this job to its completion, including reasonable solutions to the debugging issue, support for all Emacs configurations we care about (a frequent gotcha is 32-bit builds --with-wide-int; and what about --enable-check-lisp-object-type? etc.), and then support it during the initial stages of its use on master, when people will almost certainly report problems with it that were never heard of before. I realize that the above sounds negative, and maybe even discouraging, and I apologize for that. But please bear with me: if I'm allowed to put on my project management cap, I have some bitter experience with several experimental features which required a significant amount of work, but were abandoned before becoming mature, or were merged although they weren't mature enough, or whose developers disappeared without a trace, leaving us to cope with the problems reported against those features without enough knowledge about the code. So I think for such a radical new feature, which affects how we compile Lisp, we (at least I personally) would like to avoid such disappointments as much as practically possible. Thanks.