On Wednesday 30 June 2010 11:52:33 Cactus wrote: > On Jun 30, 10:32 am, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > On Tuesday 29 June 2010 22:25:44 Cactus wrote: > > > On Jun 29, 8:38 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > > > On Friday 25 June 2010 20:16:15 Jason Moxham wrote: > > > > > Hi > > > > > > > > > > These cpu's also have no support from gcc , so again I think we > > > > > should certainly remove them > > > > > > > > > > gmicro > > > > > i860 > > > > > ibm032 or 032 or ROMP > > > > > uxp or xp fujitsu 32bit vector supercomputer > > > > > > > > I have removed all traces of the above cpus and I will start to chop > > > > out the old OS'es . Note: this does not mean that we will not run > > > > under these OS'es , it just means that any special conditions for > > > > them are removed . Some of these special conditions are for broken > > > > installs or very old versions which were missing certain crucial > > > > header files etc , so later versions may work , but I would not count > > > > on it , and if they dont then tough :) > > > > > > > > Thinking about what other changes I would like to make to simplify > > > > things a bit , I released that most of the other changes would > > > > involve Brian making similar changes to the vcproj files . A few of > > > > the simpler name changes I am sure I can do a simple text replacement > > > > of the vcproj files, but most of the other stuff would need Brian's > > > > involvement. So it seems that the best course forward to avoid this > > > > duplication of effort is to get the windows port following the unix > > > > one automatically. > > > > > > The big issue for me here is not making the changes on Windows but in > > > working out what has happened on Linux and what this means for the > > > Windows build. > > > > > > If the changes are properly documented before they are done the effort > > > would not then be large, albeit a bit tedious tedious. > > > > I will try to post to the list all relevant changes so you can get the > > heads up. Some of the changes I will do when I get a spare hour or two , > > I wouldn't do them otherwise as they are not terribly important , but it > > can make work for you which could be seen as pretty pointless. > > > > > > The justification for simplifying our build system is that 50% of > > > > errors are build system related , and unfortunately autotools is a > > > > very poor design , it requires you to understand it internals to use > > > > it. > > > > > > > > 1) write our own build system starting with x86 and work thru the > > > > other major cpu's/OSes one at a time. This is TOO much work , we are > > > > not taking advantage of other peoples work on "boring" stuff , MPIR > > > > is about math not build systems. > > > > > > Much as I would like to see this, I agree that it would involve a huge > > > effort. > > > > > > > 2) We could write a simple script which does a basic build , but it > > > > would make windows a second class build environment unless we > > > > re-implement most features of a make system.There are two aspects to > > > > this , 1) to get the build optimal and 2) be able to debug and > > > > develop with windows. > > > > > > I am not sure about this one as I don't fully understand the > > > capabilities you envisage. > > > > I mean a script which would select a code path based on cpu , and then > > use cl.exe to compile and link everything in that path. The resultant > > library should be just as good for the user , but for the developer many > > it would be a pain to use. > > > > > > 3) We could convert to eg) cmake which supports unix and windows , > > > > this appears to be the most attractive option , this would take a > > > > fair amount of time. cmake produces native vcproj files for windows > > > > and makefiles for linux , so both camp's would be in their NATIVE > > > > elements. > > > > > > This is attractive as it would maintain a native Windows build > > > capability. > > > > > > > 4) Get autotools to run NATIVE in windows with MSVC . What I have in > > > > mind is really a trick , there are two parts to it , 1) get it use > > > > cl.exe instead of gcc.exe 2) hide the fact that we are running under > > > > another shell. > > > > > > > > autotools can run cl.exe , no problem , just like it can run cc or > > > > icc , the options are a little different , but a script can easily > > > > take care of that (as long as everything is one-to-one) , once we > > > > have this bit , then we could get a MSVC compile under cygwin or > > > > minGW . The next stage is to have a "hidden install" of minGW so we > > > > can run autotools, (just like we do for yasm under linux). > > > > > > I am far from convinced that this will provide a decent native Windows > > > build. > > > > > > Turning WIndows into a poor man's version of Linux does not appeal to > > > me as it almost always involves abandoning Windows conventions, For > > > example, non standard installation directories have to be used to > > > avoid spaces in paths whiich almost invaraibly kill Unix tools. > > > > > > > 5) Just the leave the system as it is. > > > > > > > > My thoughts are these > > > > 1) Insane > > > > > > Agreed. > > > > > > > 2) The present configure.bat,make.bat emulate what it would achieve , > > > > but would make development on a windows system awkward. > > > > > > It would be hard to emulate the FAT build but I have often wondered > > > whether it would be possible to automate the generation of *.vcproj > > > files from Unix makefiles. > > > > I have not considered FAT builds. > > > > > > 3) This seems like the best long term solution , to use a build > > > > system which will handle all modern OS'es , but it means a lot of > > > > work > > > > > > I have never used CMAKE but it has a strong following. > > > > I have never used it either :) > > > > > > 4) We should be able to do this with a few weeks hacking > > > > > > Can it be done without turning Windows into a poor man's Linux? > > > > > > > 5) Will keep Brian busy :) > > > > > > That depends on what is now planned :-) > > > > > > > Note: this does not address the issue that the assembler code for > > > > linux and windows are different , but I dont believe this to be a > > > > major obstical at the moment. > > > > > > But the proliferation of assembler is by far the biggest task that I > > > face as it petty well always involves a partial rewrite. > > > > I had always assumed it was fairly painless , as you always manage to > > convert them within a day or two :) > > Unfortunately it can be quite hard work. On Windows there are two > types of functions - leaf functions and frame functions. > > Leaf functions can only use rax, rcx, rdx, r8, r9, r10 and r11 but > offer a major advantage in that they don't require expliicit exception > support. > > A lot of your assembler code is agonisingly close to being put in this > from but the fact that Linux has two additional scratch registers (rsi > and rdi) considerably complicates the conversion. In consequence I > usually have to look for ways of reusing registers and this often > involves a lot of code analysis. If I find a way of doing this, I then > have to redesign your code with the fewer registers and then switch > registers to take account of the different calling conventions; > > Linux: rdi, rsi, rdx, rcx, r8, r9, 8(rsp), 16(rsp) .... > Windows: rcx, rdx, r8, r9, [rsp+40], [rsp+48] ... > > Frame functions can save and restore other registers and hence use > them. But they have do this only at a single function entry point > (save) and at single function exit point (restore). Although your > code is pretty good in saving registers at the start, it makes a lot > of use of multiple exit points all of which I have to change to a > single exit point. When these multiple exits are a part of macro > expansions this remapping becomes diffucult and error prone. In > consequence I often have to spend a lot of time in low level debugging > to get this right. I also have to worry about whether any of this > messes up your optimisation efforts (I suspect I do a bad job here). > > You are right that I can usually do this in a couple of days. But it > is often an intensive effort. On the other hand it is at least an > intellectual challenge whereas the other build changes are nothing but > pure tedium :-) >
More tedium ahead warning...... The pre-build file fac_ui.h , will be incorporated into fac_ui.c removing the need to generate it. Same for psqr.h , and probably the other two when I get around to it. > However, I think we can do several things that might make the WIndows > build much simpler now. First of all, the big differences between > Linux and Windows occur on x64. The libraries built with mingw for > win32 work with Visual Studio and, I assume, use the assembler > suppport. So I can drop Visual Studio support for win32 without much > of a penaalty. This would be a significant simplification. > Yep , sounds good , although wasn't there some problem with mixing them(I dont think this is MPIR specific ) Trac ticket 220 , cant read it at the mo , trac is down > And, now that we have published Visual Studio 2008 and 2010 support > for MPIR 2.1.1, I can drop support for Visual Studio 2008 in future > MPIR releases. > I personally think this is too soon , but I dont have to maintain them. > 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-de...@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.
