On Dec 22, 2011, at 5:15 PM, "Nathan Binkert" <[email protected]> wrote:
>> Nathan Binkert wrote: >> What do you mean Alpha "doesn't work like it's supposed to". It works >> how it works. The only time you're going to "rip support back out" is if we >> *remove* alpha. That's unlikely to happen any time soon if ever. What's >> more likely is that we eventually have support for multiple ISAs in one >> binary and IMHO this is way better than a #ifdef. My preference would be to >> *never* have an ISA specific #ifdef in the tree. >> >> I feel very strongly about this. If you look at how other software >> systems (linux, *bsd, etc.) work, they follow this idiom. >> >> Gabe Black wrote: >> I think this may be the third time explaining this, but no, I'm not >> talking about ripping out Alpha. The fact that the PAL bit shows up when you >> can instAddr is wrong. It's that way because O3 wouldn't work otherwise, and >> we had a lengthy conversation about that a while ago. Recently when Anders >> wrote the list about this specific patch I also explained how this was >> wrong. Alpha doesn't work the way it's supposed to, and when it's fixed >> *this* support will need to be ripped back out. I don't want a hack to work >> around a deficiency of O3 to turn into a full fledged feature. Also, if you >> look at the snippet of code I called out in my most recent email, you can >> see how to do this conditionally without an ifdef. > > I guess my preference would be that we select this patch if the fix that > you're talking about is a few months out (which has a habit of becoming > forever). If you truly do have plans to fix this (more than a belief that it > would be nice to have). Then I'd be happy to have the one you prefer. I'm > also happy to have a comment saying that the constant should be ripped out of > the ISAs if it is ever removed from O3. I also wouldn't mind putting O3 in > the name to make it more obvious. I agree with Nate. Removing a patch be it implemented in one way or another is as simple as reversing the change in the repository history. If it's implemented in one way or another that shouldn't really matter. In either case simply create a bug report for the fix you intend to implement and then create a dependent bug to remove whatever changeset set this becomes. The end game for this becomes no one can fix issues in the simulator someone else intends to fix some part of the code it touches in the future and only one person can ever change anything. On a related point, there have been several cases in the last couple of weeks where the lines of discussion about a patch has far exceeded the number of lines in a patch. This isn't tenable. In the grand scheme of things these changes are pretty inconsequential. At worst they'll provide for a minor annoyance in the future, and everyone's limited bandwidth should be spent on the bigger issues. Ali _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
