On Mon, Jun 6, 2016 at 1:27 PM Bjoern A. Zeeb < [email protected]> wrote:
> > One thing people need to remember however is that retiring (currently) > unusable code does not mean that the code disappears, it sits in attic and > could be brought back; the effort to get it working is needed now and will > be then. The question simply is how likely is it going to happen and when > does the cost of keeping it around by far exceed the cost of resurrecting > it. > I agree with Bjoern's last sentence about it being an issue of likelihoods and relative costs. I think it's worth noting that (1) the decision to retire an ISA will have a (possibly large) impact on the likelihood of it being used or improved, and (2) the cost of incremental updates as changes are made to keep something from regressing functionally is much lower than the cost of deferring those same updates to some future point in time. As far as #1: As long as an ISA is available in the head, and functional enough to pass the current regression tests, a potential user may come along and find that the existing level of support is good enough for them, or close enough that it's worth their effort to make it so. (And it's this latter case that's the only hope for these ISAs to move forward.) Once the bar for reaching this point is raised by adding the steps of determining that gem5 *used to* support the ISA of interest, finding and extracting the old revision that still had that support in it, and very likely needing to do who knows how much work to bring the ISA support back in sync with the head of the repo before being able to reasonably make further enhancements, then the likelihood of anyone crossing that threshold is going to be dramatically lowered. Which leads to #2: Basically the only way you win by retiring code is if that code is never resurrected. I'd say the lower bound on the cost of resurrecting the code is the same as the incremental cost of keeping the code alive, and that's a very optimistic lower bound. In practice, whoever faces the task of resurrecting the code won't know which past changes actually broke things, won't be the person who made those changes and thus, once the guilty changes are identified, will have to reverse-engineer them to see how to apply them to the old ISA, and will be faced with the task of fixing a number of things en masse rather than one at a time. In addition, there's a good chance that someone considering taking this on is new to gem5 and unfamiliar with the code to begin with, unlike the person who is committing patches and could perform the incremental updates. Please note that I'm not saying we should never retire anything; I just don't want us to use the "well we can always resurrect it from the repo" argument to take the decision more lightly than we ought. It would also be nice to keep in mind that some of the issues raised here could be addressed in other ways. For example, with respect to user expectations, there is already some documentation on the wiki about the level of support for various ISAs: http://gem5.org/Architecture_Support http://gem5.org/Status_Matrix Regardless of the outcome here, it would be good to keep that information up to date and maybe feature it more prominently so that new users are aware of it. Perhaps less-supported ISAs could print a warning and a link to these pages when they are used. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
