I just figured out a rather annoying bug in the CPU where the
profile event got scheduled at a totally bogus time which killed the
simulation. The problem is that there's a "profile" parameter in both
the atomic simple CPU and the base CPU. The atomic simple CPU sets it's
version of "profile" at some point but the base CPU one never does. I'm
guessing that's because the atomic CPU's definition masks the other when
the parameter values get loaded up. Then, in the C++, if you refer to
the "profile" member variable of the params struct, the hidden version
is in scope that never got populated.
There's several different things I can see as the "right" thing to
do in this situation, but I'm sure what it's doing right now isn't it.
First, we could say this sort of thing (params overwriting each other)
is illegal, and we throw an error when it happens. This seems the most
reasonable since you'd probably have a hard time even setting the hidden
version in python. The other version, which at least would prevent wild
dangling values, would be to initialize both versions of the parameter
according to their defaults.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
