We could still use GCC only on linux. But we'd have to be careful that yasm still got built on MinGW.
Bill. On 22 May 2012 15:19, 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). > > Bill. > > On 22 May 2012 15:14, Brian Gladman <b...@gladman.plus.com> wrote: >> On Tue, 22 May 2012 14:37:26 +0100 >> Bill Hart <goodwillh...@googlemail.com> wrote: >> >>> I agree with that explanation. However, I should add that it is >>> largely for historical reasons. >>> >>> MPIR originally planned to support MSVC out-of-the-box (as did Sage >>> once). One reason for this is that many Windows developers use MSVC. >>> Brian Gladman has been successfully providing that ability (actually >>> from before the MPIR fork began). And it seems to be widely used. >>> >>> And one aspect of the plan to support MSVC is to use a portable >>> assembler. For a while, the same code was used for Windows and Linux. >>> But it became impossible to maintain, so we gave up and separated it. >>> >>> These days things look different to the way they did back then. >>> MinGW64 is available providing even assembly support on Windows 64. >>> And oddly enough, MSVC doesn't support 64 bit inline assembly. So >>> actually, MinGW64 has turned out to be a much more serious option in >>> the long run. That wasn't predictable when we started work on the MPIR >>> fork. >> >> However, for MPIR the lack of in-line assembly support is not a >> big issue since the vast majority of the assembler code is provided as >> fully self standing assembler routines. >> >> What is more difficult is the change in the ABI and the extent to which >> mingw64 supports the Windows ABI. As I don't use mingw64, I don't know >> the answer here but I suspect that exception handling support might not >> be fully compliant (I would be pleased to be proved wrong about this). >> >> I am also unclear when MPIR assembler code is used with mingw64, which >> actual assembler code is used. If it is my Windows assembler code (in >> x86_64w) there is no guarantee that it will work as I design this only >> to comply with the ABI as offerred by the Microsoft and Intel >> compilers, not GCC. It might well work with GCC to some extent but I >> don't do anything to ensure this. >> >>> Another issue was that many assembly programmers such as myself, who >>> grew up on Windows, use Intel format, rather than AT&T format. >>> Unfortunately, GCC's support for this is flaky. We anticipated drawing >>> from the large pool of assembly expertise amongst Windows developers, >>> and felt that using Yasm (with Intel format) would be more attractive. >>> Unfortunately, only Brian Gladman has been contributing Windows >>> assembly code, and on linux, pretty much only Jason Moxham has been >>> contributing. But he prefers AT&T code. >>> >>> Given that there are a large number of people using the MSVC support >>> in MPIR, I don't think we can change this in the near term. However, >>> it would be possible to switch to solely using GCC on linux and not >>> Yasm. But someone would have to commit the time to porting all the >>> code across. If you can find someone willing to do that, then provided >>> no performance regressions, I'd support doing that. We could then >>> ditch building Yasm on Linux, which would save some headaches for >>> Sage. >> >> The use of YASM was a compromise between Unix/Linux and Windows >> needs. The logic if we give up this compromise is to use the native >> assemblers - GAS on Unix/Linux and MASM on Windows. But whether >> mingw64 could then use the Unix/Linux GAS assembler code or the Windows >> MASM assembler code is something that would have to be considered. >> >> Nevertheless the need to add YASM for building on Windows instead of >> the native assembler (MASM) involves significant compromises which >> would be removed if I switched to MASM. >> >> Maybe a mingw64 user (or guru) could clarify what ABI (including >> exception handling and stack unwinding support) is used on mingw64 and >> which MPIR assembler code is used when MPIR is built with x64 assembler >> support? >> >> 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.
