emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp JIT Compiler


From: Tom Tromey
Subject: Re: Emacs Lisp JIT Compiler
Date: Fri, 24 Aug 2018 11:54:06 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux)

>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:

Eli> I made the feature/libjit branch build with MinGW.  The
Eli> "--with-wide-int" configuration still doesn't work correctly, although
Eli> I made quite a few changes to support that.  A 32-bit build without
Eli> wide ints successfully bootstrapped, and I believe a 64-bit MinGW
Eli> build should work as well, although I didn't try that.

Thanks for doing this.

Eli> Tom, I'd appreciate your review on the changes, especially changes for
Eli> the function signatures, as I found a few of them to be at odds with
Eli> the actual functions they represent, and so I wonder whether I missed
Eli> some subtlety.

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.

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.

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.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]