On Nov 15, 2010, at 8:29 PM, Gabriel Michael Black wrote: > It seems like our notion of serializing came from the definition Alpha uses, > and sometimes we need a stronger one. X86 is going to have similar issues in > some cases, although I couldn't necessarily list them for you off hand. The > "nuke everything" flag your proposing might be the best solution because I > doubt we'd ever need anything stronger than that. Maybe you could make the > CPU stop fetching too, but I don't see how that would be useful and it's > probably very hard to do. > > This also highlights the usefulness of target tests of particular features > like changing the ISA and then immediately using it as apposed to getting > specific workloads to work. The compiler, code author, etc., only wants to > achieve a functional result, and they'll probably use the same structure and > features over and over again since those work well, are equivalently good to > the other options, etc. There are swathes of x86, which granted is very > large, that aren't implemented at all and Linux boots just fine, but > depending on how picky you are you could say those areas are severely broken. > The same thing could be happening less intentionally elsewhere.
I don't mean to pick on you Gabe, I'm just surprised that when the compiler inserts wr asi in happens to also include enough padding before it needs it that it worked in the past. I think the load that used it would minimally have to be a cache line away. It's just bizarre to me unless there was an interlock on wr asi that they knew about. Anyway, I've added a flag called isSquashState. I don't like the name, so please propose a better one. isSquashAfter? After commit in the o3 cpu it checks for the flag and squashes the world. This clears up the issue enough for gzip to start running. I should know in 3 hours if it is sufficient. Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
