It's important to distinguish between M5 making sense, and the code
it's executing making sense. We shouldn't (and I hope don't) have any
asserts that check conditions controllable from the simulated code
since those should generally just cause a fault and may, as you point
out, be mispeculated. It's fine to check that M5 is internally
consistent, though. This is supposed to work in all the CPU models and
as far as I know generally does. M5's CPU models should, to the first
order, correctly do whatever whacky, nonsensical things the
instruction memory tells it to do without complaining. If you've found
a case where it doesn't (which has happened before) please let us know
so we can fix it.
Gabe
Quoting Min Kyu Jeong <[email protected]>:
Is it possible that the speculatively fetched instructions can cause
programming assertions to fail? Until a branch is resolved, whatever (even
non-instructions) in the predicted path could be fetched and decoded. Can't
assertions on instruction sanity fail for those?
I am trying to make O3 CPU model for ARM working. In many cases the first
instruction is a branch followed by a interrupt vector table. I was
wondering if such cases exist for other CPU models and if it is, handled
how.
Thanks,
Min
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
