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 Note these are only entries in longlong.h , but as we want to get rid of it someday , all the cpu types in it have to go somewhere or be removed. Jason On Friday 25 June 2010 18:33:31 Jason Moxham wrote: > Hi > > I've have updated yasm to the latest svn , unfortunately it was not as easy > as I thought , I was going to take a diff of the yasm svn's and just apply > that to our yasm , so that we have only a small set of changes (about 1mb) > , but it didn't apply cleanly, there was a lot lot of differences in > white-space??? , and make check failed (due to white-space , as they use > text comparison for make check , which is now reliable). The main reason > for this is that many of the files in yasm are auto-generated , but I > couldn't get it to regenerate the broken files. > Anyway in the end I took our differences and applied them to yasm svn , > this works fine and I set up a "script" and diff so we can easily upgrade > at any time "mpir/yasm.diff" , the only downside is that all the yasm file > are considered new , so anyone wishing to get the svn (or see what has > changed) has a larger download ( we are not interested in what has changed > in yasm though!!! , it is just yasm svn rev 2334 , plus our changes in > mpir/yasm.diff , then autogen'ed) > > I have removed all support for the following cpu's > a29k > clipper > i960 > i960mx > m88000 or m88k > m88110 > ns32000 or ns32k > pyr or pyramid > z8000 > z8000x > > Note: gcc did NOT support them , so clearly they are dead , they could > still possibly be used with a generic C build , but you would need an old > enough compiler , which would probably break elsewhere. > > I have removed the demos from the library and I will put them on the > webpage once I get them to work outside of the library , there are some > dependencies on undocumented internals. > There was also a emacs "profile" for help with editing m4'ed asm files, > this was in the mpn directory! , I could put it on the website , but I > don't think it is worth it. > > There are some more old cpu's which it maybe good to drop all (or explicit) > support , I post a list later with some details for feedback. > > It would also simplify things if we could drop support for IRIX , which is > different enough to complicate autotools , I will look more closely into it > to see if this is a good idea or not. > > Jason > > On Thursday 24 June 2010 06:04:31 jason wrote: > > Hi > > > > Hopefully we can release mpir-2.1.1 today , then this is what I plan > > to do. I dont have a lot of time in the next month so I'll will mainly > > concentrate on small items ie bug fixing/cleaning-up , stuff I can do > > in a few hours or in fits and starts , nothing where I have to sit > > down for a day or two :( > > > > On Jun 2, 10:18 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > > Hi , here are some thoughts about what we should/could do for the next > > > release. > > > > > > 1) Upgrade yasm to the latest (easy) > > > > Yes > > > > > 2) Upgrade gnu config to the latest ( dont know how difficult that is , > > > but it could fix some niggles we have , and it might simplify our > > > specialisations. > > > > > > 3) Upgrade to the latest autotools/libtool ( some distros are moving > > > over to the latest 2.2 , we may need/want to do the same , again dont > > > know what this involves) > > > > > > 4) A few assembler functions to add > > > > Yes > > > > > 5) Move demo's out of the library onto the web page > > > > Yes > > > > > 6) Get rid of ancient cpus/compilers ( we will still work under C , if > > > anyone cares) , this would simplify configure a bit , cray,pyramid, > > > z8000,list,clipper,.... > > > > Yes > > These chips a29k clipper i960 m88k ns32k pyr z8000 z8000x are not > > supported in the current GCC so I will remove asm code and all the > > configure bumf that goes with it. Also maybe vax and cray(old non ieee > > standard) , also the lisp directory should be on the website , not in > > the library. > > There is also some configure guff for cpu's which have already been > > removed , clean all this up. > > > > > 7) Make configure run faster , I'm sure we can remove some of the tests > > > , I can't believe they are still needed , and/or share the test results > > > with yasm. > > > > > > 8) make make check parallel , it can be done. > > > > > > 9) Some of the changes we have made , have not been finished , finish > > > them. > > > > > > 10) Split configure into two , ie standard and MPIR specific , should > > > make the maintenance easier , this is fairly ambitious :) > > > > > > 11) drop support for building/running on FAT file systems ( ie file > > > name 8.3 format) > > > > > > 12) simple command line build for windows ( not dependant of vcproj > > > files) > > > > > > 13) fix some known bugs > > > > Yes > > > > > 14) When we update stuff , there are many places where you have to fill > > > in the same info , make it automatic (autotools can do this , it's just > > > not been set up that way) > > > > Yes , I'll start , and we will see how it goes > > > > Also remove the pre-build stuff , it is needlessly complicated and > > only really needed for nail builds , which we dont support . I'll put > > the files generated in the mpn/cpu/ directorys or rather links to the > > only two variants we support. > > > > Plenty of other little bits to do :) > > > > Jason > > > > > Some of these are trickier than others , but my aim is to simplify the > > > system (the non-computational parts of it) > > > > > > Bets now being taken on what % will get done :) > > > > > > Thoughts? > > > > > > 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.
