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