One thing we could do is remove support for chips with a "rolling wall". If the manufacturing date for that architecture is more than 10, 15 or 20 years ago, say, we could remove support for it.
Funnily enough, this may not cut much out. The Intel 80386 for example ceased to be made in September 2007!! Perhaps if we take the 21 years of manufacture for this CPU as a benchmark, that would mean we cut out any CPU's which were first manufactured 21 years or more ago, i.e. before March 1988. Often military, aerospace and embedded applications see the lifespans of chips hyperextended. Perhaps, given that MPIR will still run on them, with C support only, we can afford to have a more recent wall, say 15 years ago. That would cut out all 80486's, some pentiums, but not pentium pros, etc. Bill. 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: > > On Monday 23 March 2009 16:45:53 Bill Hart wrote: >> 2009/3/23 Jason Moxham <ja...@njkfrudils.plus.com>: >> > MPFR is based on mpn and mpz , not mpf . >> >> OK, I didn't seem to know that. I probably should have though. >> >> > I suppose we get remove mpf from the default MPIR build , and only build >> > mpf if we configure with --enable-gmp-compat which could switch on all >> > the other old stuff we would like to remove. >> >> Would that actually cut down the size of MPIR? >> > > No , it would be bigger and more complex > >> I also don't see how say switching off nails and mpbsd, etc, would >> actually save development effort. If someone types --enable-gmp-compat >> then all that is going to have to be there (and work) anyway. >> >> Bill. > > > What about some of the old cpu archs , mpir would still run on them but just > in C > >> >> > On Monday 23 March 2009 16:18:56 Bill Hart wrote: >> >> Hi Mariah, >> >> >> >> This would make MPIR unusable in Sage as a drop in replacement for >> >> GMP, and it would prevent people from using MPIR instead of GMP as a >> >> base for MPFR. >> >> >> >> However, if MPFR becomes independent of the mpf layer in GMP, as I >> >> suspect it may in the future, then it is a possibility worth >> >> considering. Though I'd still be worried about packages which want to >> >> use the mpf layer from GMP and use MPIR as a drop-in replacement. >> >> >> >> Bill. >> >> >> >> 2009/3/23 Mariah <mariah.le...@gmail.com>: >> >> > Bill, >> >> > >> >> > As a suggestion on something that could be removed from >> >> > MPIR, had you considered removing the mpf code? I was >> >> > under the impression that MPIR was going to concentrate on >> >> > multiple-precision integers and rationals, and >> >> > leave multiple-precision floating-point to MPFR. >> >> > >> >> > Mariah >> >> > >> >> > On Mar 20, 11:30 pm, Gonzalo Tornaria <torna...@gmail.com> wrote: >> >> >> On Fri, Mar 20, 2009 at 11:46 PM, Bill Hart >> >> >> <goodwillh...@googlemail.com> >> > >> > wrote: >> >> >> > I suppose it's just aggregation. >> >> >> > >> >> >> > Maybe we need to get rid of the bit that says, "overall licensed >> >> >> > LGPL". Is that still permitted, when some component of the distro >> >> >> > is GPL? >> >> >> >> >> >> Sounds like a good idea. >> >> >> >> >> >> > Actually the reason for me wanting to perhaps get rid of the demos >> >> >> > was more to do with the fact that I don't know anyone who uses >> >> >> > them. Very clear examples in the documentation would probably be >> >> >> > much more useful. >> >> >> >> >> >> I haven't looked at the demos, but I did want to use the benchmark >> >> >> and I didn't get to it until your posted howto (not that it was that >> >> >> hard, but I was lazy). I expect more people will use it if "make >> >> >> bench" just works. >> >> >> >> >> >> I'm not arguing to keep the demos, nor I am saying that benchmark >> >> >> code should not be rewritten and expanded. But just not because of >> >> >> licensing. >> >> >> >> >> >> > Anyhow, it's no big deal. Just an idea. I suppose the thing that >> >> >> > set off that thought process for me was Brian saying it took >> >> >> > forever to check out MPIR via his internet connection. We are >> >> >> > carrying some fat. There's no reason to not have the demos on the >> >> >> > website. Can't come up with as clear a case for leaving them in the >> >> >> > library source. >> >> >> >> >> >> Sounds fair if demos are indeed big, I have no idea how much space >> >> >> they take (otoh, I think Brian was updating the root of the svn repo >> >> >> instead of just trunk). The benchmark code is about 6kb compressed... >> >> >> not too bad. >> >> >> >> >> >> Gonzalo >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
