On 07/06/2016, 17:27, "gem5-dev on behalf of Steve Reinhardt" <gem5-dev-boun...@gem5.org on behalf of ste...@gmail.com> wrote:
>On Mon, Jun 6, 2016 at 1:27 PM Bjoern A. Zeeb < >bzeeb-li...@lists.zabbadoz.net> 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. You raise a valid point. However, I don¹t completely agree with your the conclusion. For complex work, say reworking register interfaces (e.g., Nathanael¹s patch), modifying every single ISA adds a significant development overhead. There is also a very real cost associated with having to re-compile gem5 test all of the ISA/Ruby configuration we ³support". There are two things we could do to improve the situation without completely retiring ISAs: * Improved build system reuse. We could significantly shorten the build/test cycle by only compiling device models and the core framework once instead of for each ISA/Ruby configuration. * We should get rid of long tests for unsupported ISAs and make the remaining tests functional only (i.e., not diff stats or out files). This would make stat refreshes (which pretty much every single non-trivial change requires) much more manageable. I¹m planning to do similar things for some of the ARM tests that are more functional in nature. >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. In that case, we Alpha would still be a candidate for removal. The likelihood that someone will ever need it for research seems very low and having to resurrect it seems extremely unlikely. A simulator such as SimH seems more suitable for what can only be described as retro computing (which I enjoy, but it¹s not gem5). >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. Updating these pages is definitely something we should do regardless of whether we retire existing ISAs or not. We should make sure that both the build system and the generated binary print a warning if a user wants to use one of the unmaintained ISAs. This should help in setting expectations. //Andreas 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. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
