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?
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
