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 10:46:50 +0000 Message-ID: References: <838smzq9iz.fsf@gnu.org> <8336d6rfgy.fsf@gnu.org> <83sgl6p1xa.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="117193"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 27 11:47:04 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 1ikn96-000UMa-Bv for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 11:47:04 +0100 Original-Received: from localhost ([::1]:33838 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikn95-0007n7-5V for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 05:47:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53892) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikn8y-0007n0-CM for emacs-devel@gnu.org; Fri, 27 Dec 2019 05:46:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ikn8x-0005sC-3r for emacs-devel@gnu.org; Fri, 27 Dec 2019 05:46:56 -0500 Original-Received: from mx.sdf.org ([205.166.94.20]:56963) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ikn8u-0005q1-LG; Fri, 27 Dec 2019 05:46:52 -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 xBRAkoKn002385 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Fri, 27 Dec 2019 10:46:51 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id xBRAko5P008288; Fri, 27 Dec 2019 10:46:50 GMT In-Reply-To: <83sgl6p1xa.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Dec 2019 11:12:33 +0200") 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:243699 Archived-At: Eli Zaretskii writes: > . 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 Correct eln are not portable (that's the reason why have some performance advantage) and they must be compiled as we compile C code. > 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? ;-) I'm not sure about libgccjit windows support (probably lacking it?) or how hard would be to put it in place. I don't have a windows machine to develop on so it's out of my reachable scope sorry. At least I see libgccjit ships already with a lot of GNU/Linux distribution. I guess this would be a dependency on a library for an optional feature, as we already have others. > 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.) Generally speaking the native compiler has to be correct exactly as the byte-interpreter has. So yes, if it's broken stepping with gdb or some other debugging technique in the generated code will probably be useful to understand why. Exaclty as we would step in the byte-interpreter. > 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. I understand your concern on this. I guess is up to me to prove the opposite with steady contribution. Thanks for the feedback Andrea -- akrl@sdf.org