> On 2011-12-22 11:09:20, Nathan Binkert wrote: > > Ali, can you take care of it? > > Gabe Black wrote: > I really don't want things implemented this way. The fact that Alpha is > an aberration and doesn't work like it's supposed to should be codified by > building support for it into all the ISAs. It should be left as an Alpha > specific hack (there is plenty of precedent) and cleaned up when possible. > The we won't have to rip support back out of all the other ISAs, or worry > about where else this misfeature has crept into. > > Gabe Black wrote: > should be codified => shouldn't be codified > > Sorry to yank you back and forth on this Anders. > > 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. > > Nathan Binkert wrote: > 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.
What was the conclusion of this discussion? - Anders ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/950/#review1782 ----------------------------------------------------------- On 2011-12-22 10:38:02, Anders Handler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/950/ > ----------------------------------------------------------- > > (Updated 2011-12-22 10:38:02) > > > Review request for Default. > > > Summary > ------- > > Alignment of PC is ALPHA specific, thus checks for ISA is needed. > > > Diffs > ----- > > src/arch/alpha/isa_traits.hh ca98021c3f96 > src/arch/arm/isa_traits.hh ca98021c3f96 > src/arch/mips/isa_traits.hh ca98021c3f96 > src/arch/power/isa_traits.hh ca98021c3f96 > src/arch/sparc/isa_traits.hh ca98021c3f96 > src/arch/x86/isa_traits.hh ca98021c3f96 > src/cpu/pc_event.cc ca98021c3f96 > > Diff: http://reviews.m5sim.org/r/950/diff > > > Testing > ------- > > > Thanks, > > Anders > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
