Good questions, Jason. SPARC is not completely dead; it's still in use at Oracle, There's also the open-source LEON design that gets used once in a while when an academic needs to do something that involves RTL, and (as I just learned via google) even has commercial support (http://www.gaisler.com). I don't know of anyone actively using it (if you're out there, please speak up!), but in many ways it's not as dead as Alpha, for example.
As far as potential benefits, I suspect that if we drop support for SPARC, we might be able to get rid of one of the levels of indirection that's used to implement register windows, though I'm not 100% sure; as that functionality might also have been adopted to cover some simpler features in other ISAs as well. Also, while the end result would be a significant simplification, I expect it would be a pretty substantial effort to rip it out, and I'm not sure who would sign up for that. With respect to long-term goals, perhaps that's something the PMC should take up at its first meeting :). I suspect you're right, that the value of supporting ISAs other than ARM and x86 is pretty marginal, but at the same time I'd philosophically rather not be a complete tool of the hegemony. As I was trying to say before, I'm not really fighting to keep it; I just don't want to take the decision too lightly, since it's likely pretty irreversible. Though perhaps if it's irreversibly broken already then officially dropping it is just truth in advertising----that's a reasonable argument too. Steve On Mon, Aug 10, 2015 at 7:41 AM Jason Power <[email protected]> wrote: > Hi everyone, > > I think there are two questions to ask ourselves here: > 1) Do we every foresee anyone wanting to run gem5 with SPARC again? It > seems pretty unlikely to me, but maybe there's a use case I'm not thinking > of. > 2) What is the long-term goal of gem5 and ISA compatibility? It seems to me > that at least 90% of gem5 users use x86 or ARM. Do we really want gem5 to > support all possible instruction sets? Do we even live up to that today? > (no, I know that POWER is broken, for instance.) As a hypothetical, If we > limit the scope of gem5 to just x86 and ARM, we may be able to reduce the > complexity of some parts of gem5 (e.g., remove unused features from the ISA > language). > > Jason > > On Fri, Aug 7, 2015 at 2:37 AM Andreas Hansson <[email protected]> > wrote: > > > Hi Steve, > > > > My main motivation, as we discussed at the ISCA workshop, is to improve > > the ratio of working vs non-working gem5 experiences. All the code that > is > > ‘half working’, MIPS, SPARC etc, brings issues from time to time, and > _no_ > > benefits from my perspective. In best case it does not confuse new > > users...and that’s best case. > > > > Andreas > > > > On 07/08/2015 05:33, "gem5-dev on behalf of Steve Reinhardt" > > <[email protected] on behalf of [email protected]> wrote: > > > > >Seems like we need to look at both the costs and the benefits of > dropping > > >support. The costs may be low, but we'd have to figure out just how > > >low---are there just a few quiet users on sparc, or is it really nobody? > > >Second, what are the benefits? It would eliminate some minor hassle, > but > > >to be honest I haven't run into any cases where maintaining support for > > >sparc was difficult. Meanwhile, as soon as we stop doing even the very > > >basic regressions we do now, it will likely become irretrievably > > >uncompilable. > > > > > >So in short, I personally wouldn't miss it, but I'd rather not be too > > >hasty > > >to jettison it just because we think we can get away with it. > > > > > >Steve > > > > > >On Thu, Aug 6, 2015 at 3:24 PM Joel Hestness <[email protected]> > > wrote: > > > > > >> What precisely are we proposing to drop here? > > >> > > >> Joel > > >> > > >> > > >> On Thu, Aug 6, 2015 at 5:02 PM, Nilay Vaish <[email protected]> > wrote: > > >> > > >> > On Thu, 6 Aug 2015, Andreas Hansson wrote: > > >> > > > >> > Any thoughts at all on the topic, or shall we go ahead? > > >> >> > > >> >> > > >> > I am ok with dropping sparc. May be we should ask on the users list > > >>as > > >> > well. > > >> > > > >> > > > >> > -- > > >> > Nilay > > >> > > > >> > _______________________________________________ > > >> > gem5-dev mailing list > > >> > [email protected] > > >> > http://m5sim.org/mailman/listinfo/gem5-dev > > >> > > > >> > > >> > > >> > > >> -- > > >> Joel Hestness > > >> PhD Candidate, Computer Architecture > > >> Dept. of Computer Science, University of Wisconsin - Madison > > >> http://pages.cs.wisc.edu/~hestness/ > > >> _______________________________________________ > > >> gem5-dev mailing list > > >> [email protected] > > >> http://m5sim.org/mailman/listinfo/gem5-dev > > >> > > >_______________________________________________ > > >gem5-dev mailing list > > >[email protected] > > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > > recipient, please notify the sender immediately and do not disclose the > > contents to any other person, use it for any purpose, or store or copy > the > > information in any medium. Thank you. > > > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > > Registered in England & Wales, Company No: 2557590 > > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
