On Nov 15, 2010, at 8:44 PM, Gabriel Michael Black wrote: > Quoting Ali Saidi <[email protected]>: > >> >> 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 >> > > No problem, I didn't think you were picking on me :-). Weren't there fake > faults introduced to ARM that were used for a similar effect? The flag > approach is better I think, but the instructions that throw that fault could > be refitted, right? The fault is another level that is even more strict. The fault requires the store queue to completely drain before continuing, while this doesn't. Retrofitting it wouldn't be enough and perhaps there are three levels. Stall rename, squash and refetch, and squash, refetch, and drain.
Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
