* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
*
That is exactly why I was concerned. I tried to find the micro-ops for the
jmp instruction to see if there was some type of format that read or wrote
to memory, but I couldn't find anything.
Scott
On Wed, Sep 17, 2014 at 12:27 AM, Steve Reinhardt via gem5-dev
gem5-dev@gem5.org wrote:
Tough to
Hi Scott,
You could run an Exec trace around the time when you are seeing strange
PCs. Just add 'Exec' (sans quotes) to your --debug-flag= command line. I'd
recommend only collecting maybe a million ticks before the problematic PC
(or the trace gets very long), and you can do this with
Actually I just noticed that the PC in the trace is 0x402088 but the jle is
at 0x402083, so maybe it's not so mysterious
Steve
On Wed, Sep 17, 2014 at 8:12 AM, Joel Hestness via gem5-dev
gem5-dev@gem5.org wrote:
Hi Scott,
You could run an Exec trace around the time when you are seeing
While we're on the topic, I'll just mention that there is a known bug with
the gem5 symbol table: there's only one symbol table and it's a global
variable, so if you have a multiprogrammed workload, you're only going to
have the symbols for the last program loaded. The rest of the code doesn't
That is interesting with the gem5 symbol table. I am only running one
program through gem5 so I don't think this is the problem (hopefully).
Joel,
Here is the code I have put to make sure I don't get the instruction
stream. This is the exact code so if you see anything wrong with pointers
or
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2400/#review5333
---
Ship it!
Thanks!
A bit of a technicality, but officially the summary
On July 28, 2014, 12:34 a.m., Andreas Hansson wrote:
Thanks for the input Amin. One high-level question: what is the main aim of
the patch? Until now we have tried to keep the timing constraints to a
minimum (without sacrificing fidelity). In general you could argue that
tBURST can
As Joel mentioned, I think the best next step would be to turn on the Exec
debug flag so you can see what the CPU is actually doing right around this
point. You're also looking at the references as they return to the CPU; if
you look at the requests on the issue side, you should be able to tell
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2378/#review5335
---
looks fine otherwise, no need to re-post IMO
src/base/inifile.cc
10 matches
Mail list logo
