Re: [PATCH] [WIP] Port feature/native-comp to Windows.

[Eli Zaretskii]

> Date: Fri, 8 May 2020 16:55:59 -0300
> From: Nicolas Bertolo <address@hidden>
> 
> I have ported the feature/native-comp branch to Windows. I have tested my 
> changes in Windows 10 x64 with
> Mingw64 GCC 10.0. Other architectures or compilers should work, but it may be 
> necessary to adjust the
> code a little bit.

Great news, thank you for working on this.

> As I said above other architectures or compilers should work, but it may be 
> necessary to change the code
> that generates calls to setjmp(), since there are many ways to do it. An 
> option would be to copy what the
> setjmp.h header does, but I do not think it is a good idea. The proper fix 
> would be to use autoconf to detect it
> somehow.

Could you elaborate why this is an issue, and what exactly are the
details that need to be adapted to a different setjmp implementation?

Also, did you try compiling the modified code with the 32-bit MinGW64
compiler?

> Another issue is that the “emacs_dir” environment variable needs to be set 
> quite early in the initialization
> process. I do not know enough about the Emacs internals to make the proper 
> changes for that, so I just
> added a dirty hack.

Why is this a problem for the native-compile version?

> There is a remaining issue involving the environment in which emacs runs. The 
> libgccjit likes to run in a
> Mingw64 environment, so it can find the assembler, linker, etc.

What do you mean by Mingw64 environment?  Do you mean the MSYS
environment, i.e. the one that uses Bash and can run Unix shell
scripts?  If so, why is that needed?  Compiler passes are native
Windows programs, not MSYS programs.  Is this something special to how
libgccjit was ported to MinGW?

> This is means that Emacs needs to run in a pseudo-Unix
> environment. I don’t like this since this environment would be
> propagated to other processes launched by Emacs, and they may not
> like this.

This should be fixed, but I don't think I understand enough to propose
the way of fixing it.

> I have thought about a simple fix to this but I haven’t implemented it yet. 
> The Emacs process that needs to
> run in a Mingw64 environment is actually the subprocess that performs the 
> compilation, not the main
> process that runs the editor. So my idea is to run this subprocess through a 
> small script that setups the
> environment that libgccjit expects without polluting the Emacs environment. 

I think describing the environment and the need for having it in this
case will be a significant first step towards resolving the problems.

> Subject: [PATCH 4/6] Handle LISP_WORDS_ARE_POINTERS and
>  CHECK_LISP_OBJECT_TYPE.
> 
> * src/comp.c: Introduce the Lisp_X, Lisp_Word, and Lisp_Word_tag
> types. These types are used instead of long or long long. Use
> emacs_int_type and emacs_uint_types where appropriate.
> (emit_coerce): Add special logic that handles the case when
> Lisp_Object is a struct. This is necessary for handling the
> --enable-check-lisp-object-type configure option.
> 
> * src/lisp.h: Since libgccjit does not support opaque unions, change
> Lisp_X to be struct. This is done to ensure that the same types are
> used in the same binary. It is probably unnecessary since only a
> pointer to it is used.

Is this specific to MS-Windows?  If so, what is the MS-Windows
specific aspects of native compilation that require this?

> Subject: [PATCH 5/6] Remove a layer of indirection for access to pure storage.
> 
> * src/comp.c: Taking the address of an array is the same as casting it
> to a pointer. Therefore, the C expression `(EMACS_INT **) &pure` is in
> fact adding a layer of indirection that is not necessary. The fix is
> to cast the `pure` array to a pointer and store that in a void pointer
> that is part of the compiled shared library.

Same questions here.

Thanks.