On Tuesday, 22 May 2012, Bill Hart <goodwillh...@googlemail.com> wrote: > > > On Tuesday, 22 May 2012, Brian Gladman <b...@gladman.plus.com> wrote: >> On Tue, 22 May 2012 16:53:07 +0100 >> Bill Hart <goodwillh...@googlemail.com> wrote: >> >>> 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. >> >> Not MASM but there is a highly regarded Open Source alternative JWASM >> at http://www.japheth.de/JWasm.html which can be used: > > It's license is not accepted as free by the Debian and Fedora crowds. > > I don't know if that is something to be taken seriously or not.
Unfortunately it is. The license is not free, let alone GPL compatible. It even uses version 1 of the license which has problems in the termination clause and the deployment clause. We definitely can't make this a dependency of MPIR. > > It probably couldn't be included as part of MPIR itself, but could be made a dependency for a MinGW build. > > It wouldn't then build out-of-the-box on MinGW like GMP does which I don't like the idea of. > > It sounds very much like we should find someone to maintain gcc based Windows assembly code for MinGW. > > Any volunteers? I know no one in the Sage project cares about MinGW, but maybe some of our other MinGW users might be interested in doing this. > > Bill. > >> >> "JWasm is written in C. The source is portable and has successfully >> been tested with Open Watcom, MS VC, GCC and more." >> >>> > 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). >> >> JWASM solves that. >> >>> And, are you sure you want to rewrite all that assembly code to work >>> with MASM? What would be the main motivation for that? >> >> Its not all that hard to do and is an investment that would make my >> life easier in the medium to long term. YASM only partially >> integrates into Visual Studio and does not respect the ability to only >> assemble those source code files that have changed, which means that >> builds take a lot longer than they would with MASM. MASM also has >> better support for debug symbols. The other thing is that using MASM >> would allow MPIR to build 'out of the box' since MASM is included as a >> part of Visual Studio. >> >> Brian >> >> -- >> 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. >> >> -- 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.
