(I wrote most of this email before I saw your second message, so I'm not sure whether it still applies or not, but I figured I'd send it anyway.)
Hi Gabe, I certainly agree with your goals, but I will quibble with some of the details... On Thu, Jul 22, 2010 at 2:17 PM, Gabriel Michael Black <[email protected]> wrote: > To me there's actually a spectrum of ISA dependence, incompletely described > below: > > 1. If ISA == suchandsuch do this, otherwise do that. > 2. If ISA has characteristic such and such, do this, otherwise do that. > 3. Here, ISA, you take care of this. > 4. ISA data parameterizing non-ISA stuff. > > Number 1 is the worst since it's hard to maintain, can be cumbersome to > specify, and it isn't always clear -why- ISA suchandsuch needs a particular > behavior. I could go into a lot more detail about why I think #1 is the worst---I think you're being too kind here---but since we agree it's bad I won't bother. > I'd say number 2 is second worst, and that's what this is an example of. > It's better since it's obvious why the code is separated out and there can > be sharing between CPU models, etc., but at the same time it increases the > CPU's awareness of the ISA on it and partially breaks down the barriers of > abstraction. It also sets up special case code paths where, for instance, > only x86 on the timing CPU would possibly exhibit a certain bug. If someone > changes things for ARM and everything seems to work, they could be subtley > breaking x86 which they aren't familiar with and weren't thinking about when > they made their change. I don't really agree with this analysis... I think you can also look at #2 as a special case of #4 where the ISA parameter is a bool rather than (for example) an int. I agree there's a qualitative difference in terms of how dramatically control flow is affected, but I think it's a perspective that makes it psychologically more appealing. And the fact that it sets up special code paths is orthogonal: if there's a bug in how unaligned accesses are handled, that's only going to show up in x86 regardless of whether that code path is explicitly blocked by a HasUnalignedAccess flag or just implicitly never gets exercised because sreqLow is always NULL for non-x86 ISAs. Overall I don't disagree with your ranking; in fact we've already discussed moving the unaligned access handling for both the TLB and cache into the ISA-specific TLB and a shim, respectively, which would be an example of moving this code from case 2 to case 3. However I view it as more of a gulf, where #1 is really bad, and 2-4 are reasonable things to do, and while in general 4>3>2 there are things that are just easier to do via #2 and there's no need to unnaturally avoid that. > I think it's bad news to have a big list of yes or no checkboxes in each ISA > directory which turn on and off behaviors. This is especially true when it's > ambiguous whether to say yes or no, if the behavior changes based on > circumstances, etc., and if/when the checkbox is interpretted subtley (or > not so subtley) differently by the consumer. I'm not advocating for a huge list of ambiguous checkboxes... I'm just advocating for #2 in preference to #1, and also saying that #2 is really not so bad that we need to bend over backward to avoid it when it seems natural. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
