The files need the eol_native flag set in svn. You can use dos2unix to convert all the files.
Bill. 2009/3/5 <ja...@njkfrudils.plus.com>: > > > must be Brian script , they are all full of "\r" > which of course means the matching name is mpn_name\r not mpn_name > removing the "\r" is easy on all files, but we will probably hit the problem > again , and/or I can put a > tr -d "\r" > to delete all "\r" in that specific piece of configure > We could hit the problem in other places!!! > - Show quoted text - > On Thursday 05 March 2009 17:25:51 Bill Hart wrote: >> I don't believe so. >> >> 2009/3/5 <ja...@njkfrudils.plus.com>: >> > On Thursday 05 March 2009 16:34:23 Bill Hart wrote: >> >> At present I don't think we have any. This was always difficult to >> >> handle in yasm anyway and is an open ticket. >> >> >> >> Did you write any? If not, we can safely ignore for now. I'll add a >> >> note to the relevant ticket so that gets fixed for any multifunc files >> >> in future. >> >> >> >> Do you want to update the grep in configure and do autoconf, etc. and >> >> I'll run mpirbench again to check the 2% comes back. >> > >> > Did you edit *.as with a dos style ending ie CR/LF ? >> > - Show quoted text - >> > >> >> Bill. >> >> >> >> 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> > On Thursday 05 March 2009 16:29:30 Bill Hart wrote: >> >> >> I'd prefer to change the grep to include a search for GLOBAL_FUNC >> >> >> mpn_name. >> >> > >> >> > No problem , how do we multi-function files ? >> >> > - Show quoted text - >> >> > >> >> >> Bill. >> >> >> >> >> >> 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> >> > On Thursday 05 March 2009 16:19:32 Bill Hart wrote: >> >> >> >> Even if it is by filename, it might not recognise them now that >> >> >> >> they are .as files. >> >> >> > >> >> >> > looks like it just grep's *.asm or *.as for the keyword >> >> >> > PROLOGUE(mpn_name) so perhaps we could put PROLOGUE(mpn_name) in >> >> >> > the *.as as a empty macro? - Show quoted text - >> >> >> > >> >> >> >> 2009/3/5 Bill Hart <goodwillh...@googlemail.com>: >> >> >> >> > Don't the M4 macros PROLOGUE(mpn_blah) in the .asm files trigger >> >> >> >> > this? Now that they are .as files with GLOBAL_FUNC mpn_blah >> >> >> >> > instead of PROLOGUE(mpn_blah) it just thinks the functions don't >> >> >> >> > exist. Or does it do by filename. >> >> >> >> > >> >> >> >> > Bill. >> >> >> >> > >> >> >> >> > 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> >> >> >> On Thursday 05 March 2009 16:10:04 Bill Hart wrote: >> >> >> >> >>> Then this surely affects the Windows bench as well as the >> >> >> >> >>> linux one. I see it is used in Toom multiplication. >> >> >> >> >>> >> >> >> >> >>> Happy days. There's your 2% missing for Windows! >> >> >> >> >> >> >> >> >> >> I'm not so sure , the problem is in configure.in , before >> >> >> >> >> configure generates config.h with our HAVE_NATIVE_mpn_addlsh1_n >> >> >> >> >> etc , and now its empty >> >> >> >> > >> >> >> >> > - Show quoted text - >> >> >> >> > >> >> >> >> >> - Show quoted text - >> >> >> >> >> >> >> >> >> >>> Bill. >> >> >> >> >>> >> >> >> >> >>> 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> >> >> >>> > On Thursday 05 March 2009 16:05:46 Bill Hart wrote: >> >> >> >> >>> >> Would the loss of these also affect the mpirbench? >> >> >> >> >>> > >> >> >> >> >>> > yes >> >> >> >> >>> > - Show quoted text - >> >> >> >> >>> > >> >> >> >> >>> >> Bill. >> >> >> >> >>> >> >> >> >> >> >>> >> 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> >> >> >>> >> > The conversion from gas to yasm have lost the defines >> >> >> >> >>> >> > HAVE_NATIVE_* >> >> >> >> >>> >> > so that addlsh1_n etc dont appear in speed or try >> >> >> >> >>> >> > >> >> >> >> >>> >> > >> >> >> >> >>> >> > >> >> >> >> >>> >> > On Thursday 05 March 2009 13:38:29 Bill Hart wrote: >> >> >> >> >>> >> > - Show quoted text - >> >> >> >> >>> >> > >> >> >> >> >>> >> >> 2009/3/5 <ja...@njkfrudils.plus.com>: >> >> >> >> >>> >> >> > On Wednesday 04 March 2009 23:56:48 Bill Hart wrote: >> >> >> >> >>> >> >> >> I've had a think, especially considering the 10's of >> >> >> >> >>> >> >> >> thousands of people who will be using MPIR in Sage, >> >> >> >> >>> >> >> >> not to mention the sponsor, and I think we need to >> >> >> >> >>> >> >> >> write try tests for the mpn functions we use. >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> >> >> We could divide the work in half by one person >> >> >> >> >>> >> >> >> writing the reference tests and the other writing the >> >> >> >> >>> >> >> >> lt-try tests. I volunteer to write the reference >> >> >> >> >>> >> >> >> tests. I may be able to start this tomorrow after I >> >> >> >> >>> >> >> >> finish with converting the core 2 code to yasm. >> >> >> >> >>> >> >> > >> >> >> >> >>> >> >> > I can do half or all if you want ,although if may be >> >> >> >> >>> >> >> > better if I didn't write either , so if I have made a >> >> >> >> >>> >> >> > mistake , you are unlikely to repeat the same mistake >> >> >> >> >>> >> >> > . Note: >> >> >> >> >>> >> >> > lshift1,rshift1 are just macros on non-amd systems >> >> >> >> >>> >> >> > lshift1,rshift1 overlap requirements are same or >> >> >> >> >>> >> >> > separate ONLY redc_basecase,sumdiff has a mpn/generic >> >> >> >> >>> >> >> > written by someone else addsub returns int not limb >> >> >> >> >>> >> >> > >> >> >> >> >>> >> >> > looking at try it allready has tests for sumdiff >> >> >> >> >>> >> >> > ,addlsh1 ,sublsh1 >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> None of those appear in the list when you run try >> >> >> >> >>> >> >> without parameters. We should add those to the list. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> > so we only need new tests for >> >> >> >> >>> >> >> > redc_basecase,lshift1,rshift1,addadd,addsub >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Cool. Do you want to add some tests assuming there is a >> >> >> >> >>> >> >> reference implementation available to test against, and >> >> >> >> >>> >> >> I'll write the reference implementation. That's good >> >> >> >> >>> >> >> enough for me. If a different person writes the >> >> >> >> >>> >> >> reference implementation to the original then it's a >> >> >> >> >>> >> >> pretty good test. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Bill. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> > - Show quoted text - >> >> >> >> >>> >> >> > >> >> >> >> >>> >> >> >> Bill. >> >> >> >> >>> >> >> >> >> >> >> >> >>> >> >> >> 2009/3/4 <ja...@njkfrudils.plus.com>: >> >> >> >> >>> >> >> >> > On Wednesday 04 March 2009 23:24:59 Bill Hart wrote: >> >> >> >> >>> >> >> >> >> Is there a test for lshift1, rshift1, addlsh1, >> >> >> >> >>> >> >> >> >> addrsh1, addadd, addsub, sumdiff, divebyff or >> >> >> >> >>> >> >> >> >> redc_basecase? >> >> >> >> >>> >> >> >> >> >> >> >> >> >>> >> >> >> >> Do we need tests for these? >> >> >> >> >>> >> >> >> >> >> >> >> >> >>> >> >> >> >> I know we use addadd and addsub. Do we use any of >> >> >> >> >>> >> >> >> >> the others yet? >> >> >> >> >>> >> >> >> > >> >> >> >> >>> >> >> >> > we use lshift1 rshift1 addlsh1 sublsh1 sumdiff >> >> >> >> >>> >> >> >> > redc_basecase we dont use divebyff >> >> >> >> >>> >> >> >> > make check run tests for all these , but nothing in >> >> >> >> >>> >> >> >> > ./try - Show quoted text - >> >> >> >> >>> >> >> >> > >> >> >> >> >>> >> >> >> >> Bill. >> >> >> >> >>> >> >> >> >> >> >> >> >> >>> >> >> >> >> 2009/3/4 Bill Hart <goodwillh...@googlemail.com>: >> >> >> >> >>> >> >> >> >> > 2009/3/4 <ja...@njkfrudils.plus.com>: >> >> >> >> >>> >> >> >> >> >> On Wednesday 04 March 2009 22:40:18 Bill Hart >> > >> > wrote: >> >> >> >> >>> >> >> >> >> >>> I'd like to propose a code freeze on all >> >> >> >> >>> >> >> >> >> >>> K8/K10 assembly code, which I have now >> >> >> >> >>> >> >> >> >> >>> converted to yasm format, unless serious bugs >> >> >> >> >>> >> >> >> >> >>> are uncovered. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> If we freeze the code then we can begin >> >> >> >> >>> >> >> >> >> >>> testing. I propose we wear out each and every >> >> >> >> >>> >> >> >> >> >>> file with /tests/devel/try including many >> >> >> >> >>> >> >> >> >> >>> small operands and as many different types of >> >> >> >> >>> >> >> >> >> >>> data as try can throw at it. >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >> There no point both of us running the same test >> >> >> >> >>> >> >> >> >> >> on cuda1 say , so who does which machine? >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > I am currently running tests on a K8. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > Do you want to do cuda? >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > That will be enough. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > Let me just check that: >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > wbh...@host-57-44:~/mpir-trunk/tests/devel$ >> >> >> >> >>> >> >> >> >> > ./try -s 1-50 -r 10 -S 1-50 mpn_blah blah blah >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > does something sensible according to you? >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> >>> On my machine the K8 code gets a bench of >> >> >> >> >>> >> >> >> >> >>> 15283 which is what it got before the >> >> >> >> >>> >> >> >> >> >>> conversion. Also on K10 I did cycle timings of >> >> >> >> >>> >> >> >> >> >>> all the functions we care about and they did >> >> >> >> >>> >> >> >> >> >>> not change (to within tolerances due to >> >> >> >> >>> >> >> >> >> >>> variations between runs of course). >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> I'm inclined to finish the core 2 code >> >> >> >> >>> >> >> >> >> >>> conversion tomorrow, do some cleaning up of >> >> >> >> >>> >> >> >> >> >>> the C code (insert some whitespace >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> :-)) and then release 1.0.0. It's just about >> >> >> >> >>> >> >> >> >> >>> : as much work >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> as releasing 0.9.1. >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >> wasting precious bytes with whitespace :) >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > Now we know what is causing that 2 Trillion >> >> >> >> >>> >> >> >> >> > dollar debt!! >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> >> I thought I ran my C-code thru indent first , >> >> >> >> >>> >> >> >> >> >> to use the standard format , perhaps I missed >> >> >> >> >>> >> >> >> >> >> some files. I really find difficult to believe >> >> >> >> >>> >> >> >> >> >> that people read code formated with the >> >> >> >> >>> >> >> >> >> >> standard amount of whitespace , I'm forever >> >> >> >> >>> >> >> >> >> >> scrolling up and down to try to see the rest of >> >> >> >> >>> >> >> >> >> >> the function.First thing I do when reading code >> >> >> >> >>> >> >> >> >> >> now is to delete most whitespace. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > Maybe I won't have much to do. I did see some >> >> >> >> >>> >> >> >> >> > code the other day that I would instinctively do >> >> >> >> >>> >> >> >> >> > some things to however. It's just a knee-jerk >> >> >> >> >>> >> >> >> >> > reaction. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > I used to despise whitespace too. However I did >> >> >> >> >>> >> >> >> >> > change my mind after certain other programmer >> >> >> >> >>> >> >> >> >> > told me my code was sending them crosseyed. Now >> >> >> >> >>> >> >> >> >> > I like the sense of peace that one gets from the >> >> >> >> >>> >> >> >> >> > whitespace. It's like having a spacious office >> >> >> >> >>> >> >> >> >> > as opposed to clutter. Obviously I accept it is >> >> >> >> >>> >> >> >> >> > a matter of preference and irrelevant in the >> >> >> >> >>> >> >> >> >> > scheme of things. However I have observed that >> >> >> >> >>> >> >> >> >> > the majority tend to go for space. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> >>> By the way, make check still runs the yasm >> >> >> >> >>> >> >> >> >> >>> tests. >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >> It was quite a job do disable all the tests , >> >> >> >> >>> >> >> >> >> >> so I left it , as it doesn't effect the >> >> >> >> >>> >> >> >> >> >> correctness - Show quoted text - >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > That's fine. No problem by me. >> >> >> >> >>> >> >> >> >> > >> >> >> >> >>> >> >> >> >> > Bill. >> >> >> >> >>> >> >> >> > >> >> >> >> >>> >> >> >> > - Show quoted text - >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@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 -~----------~----~----~----~------~----~------~--~---
