On 22 May 2012 16:37, Brian Gladman <b...@gladman.plus.com> wrote:
> On Tue, 22 May 2012 15:19:52 +0100
> Bill Hart <goodwillh...@googlemail.com> wrote:
>
>> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
>> linux assembly code. So indeed, for MinGW support, we probably have
>> little choice but to use a portable assembler. So it looks like we are
>> stuck with Yasm, unless we wanted to duplicate all the Windows
>> assembly code (something I personally don't want to do).
>
> Hence the problem since I am explicitly NOT supporting mingw64 - if it
> works with my assembler, this is by luck rather than design.
>
> To be honest I was content while we all worked with YASM on BOTH
> Unix/Linux and Windows since this meant that most of our assembler
> code is common and in Intel syntax (mostly only prologues and epilogues
> change).

Yes, this is another reason that we chose to use Yasm across both
Linux and Windows. It makes a lot less work for you.

I'd bet quite a lot of money that no one will volunteer to switch all
the Linux assembly code to use GCC. So I bet this is all moot anyway.

One thing is for sure though, we cannot use MASM for Linux.

>
> But if Unix/Linux support moves to GAS (as it seems to be doing), I
> then have to convert the assembler code for Windows anyway so it then
> makes sense for me to use the native Windows assembler (MASM) and avoid
> the need to install YASM (which does not work as well as MASM).
>
> But can masm64 use MASM as its assembler (my guess is no)?

MinGW64 should be able to support MASM, though it will take a few
changes in the configure files which Jason or I would have to make. Of
course it would expect to find masm64 somewhere on the system. That is
a complication, as we cannot supply masm64 with MPIR and hence we
can't guarantee it can be found. The user will essentially have to
supply the location. (I just checked and it is not on my system.) We'd
probably need to introduce a configure flag for this purpose.

On the other hand, masm64 is not Open Source. This alone may stop some
people using MPIR on Windows, as they would want to use a completely
Open Source toolchain where possible (MinGW64, Yasm, GCC).

And, are you sure you want to rewrite all that assembly code to work
with MASM? What would be the main motivation for that?

>
> It is really worth emphasising that, unless either you or Jason are
> supporting the mingw64 build of MPIR, it is NOT supported. And I don't
> want to find that I am providing this support by default.
>

Of course it makes sense for the configure/make system to be
maintained by Jason or I (or another volunteer) and we understand that
you are unable to maintain support for MinGW in addition to MSVC.

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to 
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en.

Reply via email to