I've changed the files to match the function names of
mpn/perfsqr.c to mpn/perfect_square_p.c
mpn/jacbase.c to mpn/jacobi_base.c
mpn/divis.c to mpn/divisible_p.c

and I've split out 
mpn/dc_bdiv_qr_n.c from mpn/dc_bdiv_qr.c
mpn/dc_div_qr_n.c from mpn/dc_div_qr.c

again I've not touched the build.vc* directorys . For the first 3 changes , I 
know how to do it , but I dont know how to add a file under NSVC .

I dont think I'll do any more (17 more files in the mpn dir to do) , as the 
vs2008 build will be completely broken otherwise.

Jason


On Friday 13 August 2010 17:29:53 Jason wrote:
> On Friday 13 August 2010 17:13:59 Cactus wrote:
> > On Aug 13, 4:15 pm, Jason <ja...@njkfrudils.plus.com> wrote:
> > > Hi
> > > 
> > > I changed the files
> > > pre_divrem_1.* to preinv_divrem_1.*
> > > pre_mod_1.* to preinv_mod_1.*
> > > mode1o.* to modexact_1c_odd.*
> > > 
> > > and removed the autotools bumf that went with it
> > > 
> > > This nearly completes the removal of the old fat file system support ,
> > > there are a few little bits left , but they are not worth doing at the
> > > moment as we may want to change those bit anyway later.
> > > 
> > > Jason
> > > 
> > > On Friday 13 August 2010 14:52:03 Jason wrote:
> > > > Hi
> > > > 
> > > > I've changed the files
> > > > divebyfobm1.* to divexact_byfobm1.*
> > > > dive_1.* to divexact_1.*
> > > > divebyff.* to divexact_byff.*
> > > > diveby3.* to divexact_by3c.*
> > > > 
> > > > and I renamed the function divexact_fobm1 to divexact_byfobm1
> > > > 
> > > > I not touched any files in the build.vc* directorys , but I did do
> > > > the x86w and x86_64w directorys
> > > > 
> > > > I've not changed the test file names to match ie we still have
> > > > t-dive_byff.c rather than t-divexact_byff.c
> > > > 
> > > > More to come
> > > > 
> > > > Jason
> > > > 
> > > > On Friday 13 August 2010 13:34:42 Jason wrote:
> > > > > Hi
> > > > > 
> > > > > I going to start on these autotools simplifications now , and
> > > > > hopefully the code is clean enough to finish it .
> > > > > 
> > > > > I appear to have my Windows box back alive and well , and after
> > > > > having some trouble with installation of Windows 64 (and 32) and
> > > > > MSVC , I should be able to give the Mingw64 (and 32) a go.
> > > > > 
> > > > > Jason
> > > > > 
> > > > > On Tuesday 27 July 2010 11:31:55 Jason wrote:
> > > > > > On Tuesday 27 July 2010 11:16:25 Bill Hart wrote:
> > > > > > > On 27 July 2010 11:09, Jason <ja...@njkfrudils.plus.com> wrote:
> > > > > > > > Hi
> > > > > > > > 
> > > > > > > > Just thinking about the next bit of autotools simplifications
> > > > > > > > , then these bits are all interconnected in some way.
> > > > > > > > 
> > > > > > > > Support for fat file systems(8+3 names) , ie we have a file
> > > > > > > > mpn/dive_1.c which gives us the function divexact_1 . We
> > > > > > > > already dont support fat file systems as we already have
> > > > > > > > files with names longer than 8+3 chars , so this is no great
> > > > > > > > loss. So I propose to change the file names to match the
> > > > > > > > function names.
> > > > > > > 
> > > > > > > This definitely sounds like a long overdue improvement.
> > > > > > > 
> > > > > > > > Some files ie x86/aors_n.asm or mpn/generic/popham.c provide
> > > > > > > > for two functions , and the "decision" is made at compile
> > > > > > > > time , I propose we move the "decision" to "autotools" time.
> > > > > > > 
> > > > > > > Do you mean have two symbolic links to the same file with
> > > > > > > different flags for compilation?
> > > > > > 
> > > > > > Basically the same setup we have at the moment , but when we run
> > > > > > autotools , we run "our setup script" instead , which runs
> > > > > > autotools AND "splits" aors_n.asm into add_n.asm AND sub_n.asm ,
> > > > > > that way the build system doesn't need the compilation FLAGS , ie
> > > > > > the build system is now one file=one function. The complication
> > > > > > can still exist , but are confined to our development machines ,
> > > > > > so we could write it in python(or whatever , C?)
> > > > > > 
> > > > > > > > There are lists of functions that have to be filled in
> > > > > > > > various Makefile.am 's , with the above changes we should be
> > > > > > > > able to automate it , and I think the Windows build could
> > > > > > > > benefit from the code that can list the files/functions. It
> > > > > > > > would nice if this could handle the function prototypes in
> > > > > > > > the header files as well.
> > > > > > > 
> > > > > > > This would be nice.
> > > > > > 
> > > > > > There are of course files which can have multiple entry points ,
> > > > > > ie mpn_add_n and mpn_add_nc , we would need to handle them , and
> > > > > > I think there are file which have a few functions in them (for
> > > > > > tuning only?) . Have to think about that....
> > > > > > 
> > > > > > > > I need to think about this some more , dont want to start it
> > > > > > > > and get half way through , and realize I should of done it a
> > > > > > > > different way :)
> > > > > > > > 
> > > > > > > > Jason
> > > > > > > > 
> > > > > > > > --
> > > > > > > > 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.
> > 
> > I've updated the Visual Studio 2010 builds to account for these
> > changes and
> > tested the nehalem library build.  I have not tested the other builds
> > but I
> > would be surprised if they didn't work.
> > 
> > I have also updated the Visual Studio 2008 builds in a way that I
> > think
> > will work but I no longer have Visual Studio 2008 installed so I have
> > not
> > tested these at all.
> > 
> > If people want to continue using the Visual Studio 2008 build files,
> > we will need a volunteer to maintain them.
> > 
> >     Brian
> 
> I can test VS2008 , as that is all that I have , and if the changes are
> simple enough I can maintain them , but I'm not at all familiar with MSVC
> , and I don't want to be :(
> 
> Jason

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

Reply via email to