On Wed, Jun 8, 2016 at 8:12 AM Andreas Sandberg <[email protected]> wrote:
> > > >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. > Hi Andreas, can you elaborate? I don't see anything you're saying that disagrees with what I think I said. > For complex work, say reworking register interfaces (e.g., Nathanael¹s > patch), modifying every single ISA adds a significant development > overhead. Yes, I didn't say that incrementally maintaining all the ISAs is always easy. My point is that, first, however much effort was required of Nathanael, the effort required for someone else to come back later, identify his change as one that needs to be applied to a defunct ISA, reverse engineer what he did, and then apply it, is going to be greater; and second, that greater effort, multiplied by the number of such changes that accumulate, will significantly reduce the likelihood that anyone ever does bother to resurrect an ISA, compared with the smaller effort of taking a functioning but incomplete ISA and addressing the gaps. > There is also a very real cost associated with having to > re-compile gem5 test all of the ISA/Ruby configuration we ³support". Yes, I didn't mean to imply that there weren't other costs. Your solutions below are some of the things I was thinking of when I said "some of the issues raised here could be addressed in other ways". > 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). > Yes, I don't dispute that Alpha looks like something we should rationally retire. For sentimental reasons I'd hate to see that happen, but I won't claim they are much more than that. Though perhaps there is pedagogical value in providing architecture students, who might not download SimH on their own, the opportunity to look at the ISA and weep for what could have been... >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. > Yes, I agree with this too. Steve > > //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 > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
