From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Fri, 27 Dec 2019 17:19:08 -0500 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="49111"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 27 23:19:45 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 1ikxxR-000CfA-7E for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 23:19:45 +0100 Original-Received: from localhost ([::1]:39204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikxxP-0000DD-1N for ged-emacs-devel@m.gmane.org; Fri, 27 Dec 2019 17:19:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56622) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ikxwy-0008Eg-Bs for emacs-devel@gnu.org; Fri, 27 Dec 2019 17:19:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ikxww-0007W2-Mm for emacs-devel@gnu.org; Fri, 27 Dec 2019 17:19:15 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47295) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ikxwv-0007VL-AV; Fri, 27 Dec 2019 17:19:13 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5CC2D44D633; Fri, 27 Dec 2019 17:19:12 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 06B7B44D625; Fri, 27 Dec 2019 17:19:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1577485151; bh=7yE7AzX6BPen1hXTUH7Y+ARGmDZTdWiYdh/2tuC4XRM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=fawPsG6SdYroqMTw9U2RSEZFKPl3t6hIIp/QaxkYNRZYPvOvC5an+F0nH+lRONisq d1c4Knt04hrMOzqFVif5ECT06iMoD3r6EuahCtcSHKx7W39PnCgrgVsFT9lnS2xtmQ 0wChaB3OgL963ZB/7FX4PPTutNrY1K2MlOLtPxA3+FWt3ocoHMfrOi9fT8xFd2+4Fk eLulXvwWIYFdYD1e3BeOlynm+Z+xkdDPtGxLs82cmDfk36ksCjs/LlIyI8M1j499Fu C+U3+sgNZ/MVdnn8J3okQlzW7fualqRgoqgnZ6240glskxZIHVhmU30MNUIjZOw09J jFjhhhSlwSXuw== Original-Received: from alfajor (104-222-126-118.cpe.teksavvy.com [104.222.126.118]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5EF01212B9; Fri, 27 Dec 2019 17:19:10 -0500 (EST) In-Reply-To: (Andrea Corallo's message of "Fri, 27 Dec 2019 21:02:50 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 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:243717 Archived-At: > 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. I do expect it to change over time, but that's not what I'm worried about. The worry is more the fact that since it's not very widely used AFAIK there's a higher risk it could be completely dropped at some point, or superseded by a another API that looks quite different, e.g. because it plugs into a different stage of the compiler. None of this is really foreseeable and I'd expect that it wouldn't be too hard to retarget LIMPLE to another backend (Emacs is pretty popular within the programming-language research community, so there's a fairly good chance we could find people able and willing to take on the challenge if/when it comes up, so I'm confident that it's not too serious a worry), but it's still part of the things a maintainer has to worry about. > 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. > One could potentially write another final-pass targeting C from LIMPLE. Generating C code sounds painful to me compared to using libgccjit. It must be possible to solve the Windows compatibility in a more direct way. > I've decided to use libgccjit cause I thought was the nicest technical > solution. (admittedly quite GNUish :) I think it was a sound choice. Stefan