From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp JIT Compiler Date: Fri, 24 Aug 2018 23:23:26 +0300 Message-ID: <83in3z8qf5.fsf@gnu.org> References: <87va8ej4o1.fsf@tromey.com> <87mutpiyz6.fsf@tromey.com> <701cd05f423e0c46595a3010f45414d0.squirrel@dancol.org> <520f536b5a603831c9a57a5f6f0978a2.squirrel@dancol.org> <83va8binu8.fsf@gnu.org> <87bma3i26m.fsf@tromey.com> <87in413o4k.fsf@tromey.com> <831sapav15.fsf@gnu.org> <87ftz31wht.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535142131 19319 195.159.176.226 (24 Aug 2018 20:22:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2018 20:22:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 22:22:07 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 1ftIas-0004sk-M1 for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 22:22:06 +0200 Original-Received: from localhost ([::1]:43511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftIcz-0005r8-3T for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 16:24:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftIcR-0005qi-EB for emacs-devel@gnu.org; Fri, 24 Aug 2018 16:23:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftIcO-0006Pw-8T for emacs-devel@gnu.org; Fri, 24 Aug 2018 16:23:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftIcO-0006Pd-0Y; Fri, 24 Aug 2018 16:23:40 -0400 Original-Received: from [176.228.60.248] (port=4826 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ftIcM-0008If-K2; Fri, 24 Aug 2018 16:23:39 -0400 In-reply-to: <87ftz31wht.fsf@tromey.com> (message from Tom Tromey on Fri, 24 Aug 2018 11:54:06 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:228876 Archived-At: > From: Tom Tromey > Cc: Tom Tromey , emacs-devel@gnu.org > Date: Fri, 24 Aug 2018 11:54:06 -0600 > > It looks pretty good to me. I was surprised to see the code to > dynamically load libjit, but I don't really know what restrictions the > MinGW port is subject to. In general, any library that is not strictly required for Emacs to work (i.e. it either supports an optional feature or we have fallback code to provide the same feature) should on Windows ideally be probed at run time and loaded dynamically only if it's available, because we want to allow users to run Emacs without those libraries being installed. The reason is that finding and installing all those libraries is not always easy on Windows. > There are several hunks like: > > +#if EMACS_INT_MAX <= LONG_MAX > tem = jit_value_create_nint_constant (func, jit_type_sys_int, > MOST_POSITIVE_FIXNUM); > +#else > + tem = jit_value_create_long_constant (func, jit_type_sys_longlong, > + MOST_POSITIVE_FIXNUM); > +#endif > > Here I think it would be better to define a new type at init time and > avoid #ifs in the code itself. Maybe I'm missing something, but I didn't see how to do that with just a type definition. jit_value_create_long_constant is special in that it allows to create 64-bit constants in a 32-bit build, by allocating a 64-bit buffer and storing it address in the jit_value_t object it returns. jit_value_get_long_constant is then capable to access the value in that buffer. By contrast, all the other jit_value_create_* functions store the value directly in the jit_value_t object, so they can support values that are no wider than the native intptr_t type. > I like the introduction of lisp_object_type for this reason. I think I > was being a bit lax about the types here, as you note. Most things, > like the CONSTANT macro, I think should be using lisp_object_type, > because that's the fundamental type of bytecode operations. Only > specialized spots like extracting a fixnum value or calling some C > function should be using other types. We could indeed use lisp_object_type more, but that won't save us from using jit_value_create_long_constant, as long as we want to support the --with-wide-int build. And we cannot replace the calls to jit_value_create_nint_constant with the long variant because that will make the code less efficient in 32-bit builds without wide ints. But I will take another look and see what can be done to have less #ifdef's.