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 :-)
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.
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.
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.
