Re: On elisp running native

[Andrea Corallo]

Eli Zaretskii <address@hidden> 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
-- 
address@hidden