Hi Bill, On 12/05/16 18:03, 'Bill Hart' via mpir-devel wrote: > For anyone that would like to help with porting to Windows, here are the > notes so far: > > * The asm jit we use mentions MSVC support on its website, though it > only explicitly mentions MSVC 2003. I don't see any VS solution files, > so I don't know how the build is managed (they use CMake).
If they use cmake then you ought to be able to produce VS files from CMake itself using a generator much as you'd make Unix makefiles. See: https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html So for an out of tree build for, say, c:\dev\superopt being built in c:\dev\build: c:\dev\build>cmake -G "Visual Studio 12 2013" ..\superopt c:\dev\build>msbuild You can ask msbuild to produce for any target and platform defined in the solution and project files, it will follow those. You ought to be able to build with VS 2015 using the 2013 solution files too, if needed. Whether these files will optimize the build as you need is another question entirely. I am familiar enough with cmake to know how to build various generators, but not familiar enough to know if it builds "good" VS solutions. > * Bear in mind that supporting anything other than the assembly formats > currently supported is a massive task. Alex has spent months adapting it > to work with our assembly code, though it does read quite a bit of our > yasm code and a lot of gas format assembly. It currently outputs gas > format. It can output Intel syntax (we are not sure what variety), but > that part contains some bugs (incorrect output). > > * The superoptimiser itself is written in C++11, and Alex says he > doesn't use many longs in his code. C++11 is well supported by MSVC. It has elements of C++14 and 17 too. If you switch the compiler into "C only" mode using /TC this takes you back to C89 or whatever Microsoft deemed that standard to be, but the VS2012+ compilers are fine for the default /TP mode. > * Currently there is code that is Linux specific for fixing the CPU > affinity. That would need porting. The function you need for this is SetProcessAffinityMask, GetProcessAffinityMask and the corresponding thread versions. To get them, #include <windows.h>. These functions are exported from kernel32.lib and are available from XP and up, so basically, available on any version of windows you are likely to care about as a target. > * Until today we were having a lot of problems on Intel CPUs on any OS. > AMD is more stable though still not perfect. > > * We have not tested again on a fully loaded system. We are trying that > now, after the most recent changes. We previously had problems on loaded > systems. > > * As mentioned, we do not believe timings will be consistent enough on > Windows to be able to superoptimise, but people are welcome to try and > figure out how to make it work there. At the least it is going to > require someone with a lot of Windows experience to solve that, if it is > actually possible. > > * The total amount of code asm jit + optimiser is about 32,000 lines of > code, but currently the code is in a state of flux, day-to-day > > * Alex does not have experience developing on Windows and does not have > access to a Windows machine and he is on contract to the OpenDreamKit > project, so he is not available to assist in the development of a > Windows port, other than to answer occasional questions by email. > > * Alex is currently happy to give people access to the repository on > request (if you have a GitHub account), but please understand that the > project is not in a stable state just yet. Hope that helps, Antony -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
