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.
