On Wednesday, August 27, 2014 1:13:25 AM UTC+1, Bill Hart wrote: > > I am again very interested in having Windows 64 ports of various packages. > > At the top of my list are: > > * GAP > * Singular > * Pari/GP > > by the way, GAP once used to support OS 9, the old Apple's OS, natively. (not sure at what point this was removed)
Surely, if one persists, it can be ported to MinGW-64, too. There is relatively little code to change, most nontrivial would be GAP's garbage collector. Trouble is, GAP builds runs reasonably well under Cygwin, so there is not much momentum towards such a port. Although patches for such a port would be welcome, I suppose. > Note that MinGW2 is a much better way to do this than has previously been > available. It builds packages in a tiny fraction of the time it takes to > build with MinGW. It also fixes the broken parallel make that was in MinGW. > It has a nice package manager. The compiler seems stable. It 1000% better > in every way. In my opinion, a more or less native port of various packages > to MinGW2 is quite feasible. > > Note that the flint library generated only two warnings with MSVC after we > got it building with MinGW2. > > The biggest problem by far is the upstream projects who do not accept > patches into their repositories to support Windows, and aren't willing to > make the changes to their codebase to support Windows 64. Nor do they > continue to maintain the ports once it is done. > > This attitude in the Open Source community to Windows 64 really bugs me. > It's a decade old technology, and not going anywhere. > > A port of Sage to Windows 64 is probably not a viable project. It would > take years of effort by numerous individuals to accomplish. And it would > bitrot before it was even completed. But the fact that it isn't viable > right now doesn't mean that upstream projects shouldn't support Windows 64 > so that if Sage ever wants to do such a port, it would be possible. > > Five projects Sage doesn't have to worry about are: > > * flint > * gmp/mpir > * mpfr > * gmp-ecm > * GNU Scientific library > > They support Windows fully. In fact, these projects even build on MSVC > thanks to years of effort by Brian Gladman. > > For those unfamiliar with what a port to native Windows means, here is a > description of the steps involved for an ANSI C project (it's slightly > easier to port C99 projects to MinGW2 than ANSI C, but the MSVC compiler > does not have full C99 support): > > * Replace all occurrences of long and unsigned long with alternative types > (e.g. slong, ulong in flint or mp_limb_signed_t, mp_limb_t in GMP) since a > long is only 32 bits on 64 bit Windows > > * Ensure memory allocations do not mix allocating pointers and > words/limbs, e.g. long * a =malloc(32*sizeof(long)); void ** b = (void **) > a + 16; > > * Replace all format specifiers for printf, scanf, fscanf, sscanf. This > usually implies creating a project_printf function, for example, which > accepts all the usual format specifiers, but provides new ones (e.g. %wd, > %wu) for printing e.g. slong and ulong on Windows. Then use the new > project_flintf/scanf, etc ubiquitously. > > * Replace all integer constant literals, e.g. 123L with a macro, e.g. > WORD(123) which expands to 123L or 123LL depending on the platform. Similar > macro UWORD(123) for 123UL. Use ubiquitously. > > * Place all code that requires posix functionality (pipes, etc) inside > guards so it is not built on Windows. If the functionality is important to > retain as part of the core functionality, Windows equivalents need to be > implemented. For mathematical software written in C, this is usually not > common. For other kinds of software, this can be a massive task. > > * If you wish to support MSVC, some code may need to be ported from C99 > back to ANSI C style. This is not as difficult nowadays as it used to be. > MSVC is about 90% of the way there now. They for example support mixing > declarations with other code, they have numerous C99 headers available and > so on. > > * Replace intrinsics with Windows equivalents. Most of them exist on > Windows too, just with different names. > > * Rewrite code which uses GNU C extensions. (This is not usually a big > project.) > > Porting an assembly language project is quite a lot of work. > > * There is no inline assembler in MSVC on 64 bit Windows. So there has to > be fallback C for this platform. > > * Windows uses a different ABI for assembly functions than Linux, say. One > way around this is to write macros (such as the ones in GMP) which change > the order of registers on the way into and out of an assembly function > (only the ones actually used in the function). This is usually acceptable > because it doesn't affect any loops, except for perhaps moving them to > different alignments in memory. You can expect about a 5-10% slowdown with > this method. Given the scale of effort that would be required to rewrite > all the x86_64 assembly code in a project specially for Windows, this is an > acceptable compromise. (We use a different solution in MPIR. We have a lot > of our assembly code written in Yasm, which works on Linux and Windows. We > have separate assembly versions for many functions.) > > * If you are porting to MSVC, you might like to support stack unwinding. > This is quite a bit of work, but Brian Gladman does it for example for > MPIR. It is my understanding that GMP doesn't do this, however I have not > checked recently to see if this is still the case. > > Of course quite a lot of build system work may be necessary, even if using > Autotools, for either C or assembly projects. Some versions of Autotools > break the build on Windows, so you have to find a version which works on > that platform. > > It's definitely much easier to port a project to Windows in four steps. > Linux -> Cygwin -> Cygwin 64 -> MinGW64 -> MSVC. The biggest step is from > Cygwin64 -> MinGW64. The last step is very easy nowadays. It can be done > for a medium sized project (150,000 lines of C code) in a couple of man > weeks, most of which is just fixing bugs that didn't show up on Linux/GCC. > > I understand that Sage uses things like Lisp, Java, Python, Cython, etc. > So the above doesn't help much with Sage overall. But perhaps it will help > raise awareness for projects that are using C and assembly only. > > Bill. > > On Monday, 25 August 2014 10:15:41 UTC+2, Dr. David Kirkby (Kirkby > Microwave Ltd) wrote: >> >> It seems Sage really could do with a native windows port. I am wondering >> how practical it would be to make a version which is a subset of Sage, with >> something like Qt which runs on Windows, Linux, OSX and Solaris and has >> the look and feel of those platforms. >> >> It could make a Google Summer of Code project. >> >> If a small subset could be implemented, the chances are reasonable that >> others might port more bits. If it could do more than a scientific >> calculator, that would probably be enough to get people using it. Call it >> "Mini Sage" or something similar to indicate it is not the full version. >> >> I believe that there are some are some bits of Sage that uses fork and >> has have no Windows equivalent, so those bits could be left out. Perhaps at >> a later date a complete rewrite of such bits could form other GSOC >> projects. >> >> The download size of such a subset would be smaller than the full version >> and MUCH smaller that a virtual machine image, as one doesn't need to >> include a complete operating system too. >> >> Wolfram Research did at one point offer a subset of Mathematica, which i >> think was called Calc Centre, but I think it was a bit of a flop, so I >> don't think that they sell it any more. That might be an argument for not >> doing a partial native port. >> >> If a partial port was done, avoiding the need for a browser, one could >> use its own parser and provide a more confident interface. Although many >> are critical of Mathematica's interface, it is more consistent than that >> of Sage. >> >> Dave >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
