I'm running into yet more problems with the varying interpretations of
thread status, so I'd like to get this cleared up. For reference,
here's the current enum in thread_context.hh:
enum Status
{
/// Initialized but not running yet. All CPUs start in
/// this state, but
scons: *** [build/ALPHA_FS/cpu/o3/inst_queue.fo] Error 1
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
Steve Reinhardt wrote:
I'm running into yet more problems with the varying interpretations of
thread status, so I'd like to get this cleared up. For reference,
here's the current enum in thread_context.hh:
enum Status
{
/// Initialized but not running yet. All CPUs start
I'd go with Active, Suspended, and Unallocated.
In my interpretation, the threads start in Suspended state because that
meant that you've allocated registers for that thread but it currently isn't
running. While Unallocated or Halted would mean that the CPU has no
knowledge or register binding
From the previous email, it seems there is a potential bug that is exposed
with the EAComp access.
When the ISA Parser generates instruction objects, it only generates
operands that are used in the instruction definition. This works out well
except for the case where we are only doing the
So in order of preference, my vote for the 3 state names would be:
1) Active, Inactive, Unallocated
2) Active, Suspended, Unallocated
3) Active, Halted, Unallocated
Halt seems like a word that has it's own interpretations for different ISAs
so might be best for M5 not to get tangled in that web
On Mar 17, 2009, at 1:43 AM, Steve Reinhardt wrote:
to return thread status information to the guest, and only has cases
for Active, Suspended, and Halted (and will panic if it ever queries a
thread that's Unallocated).
I'm pretty sure the patch I was recently working on for SPARC_FS
There could very well be a bug here, but I can't say since I don't have
a good picture of what's actually going wrong. There are mechanisms to
keep register indexes straight. The operands themselves have a key value
which is used to keep them in a fixed order relative to each other, and
all the
I theorize it hasn't come up, because the code isn't used to stress that
case.
On line 1668 of isa_parser.py, you'll see this:
if op_desc.is_src:
op_desc.src_reg_idx = self.numSrcRegs
self.numSrcRegs += 1
So basically, registers are read in order
The
Korey Sewell wrote:
I theorize it hasn't come up, because the code isn't used to stress
that case.
On line 1668 of isa_parser.py, you'll see this:
if op_desc.is_src:
op_desc.src_reg_idx = self.numSrcRegs
self.numSrcRegs += 1
So basically, registers
Yea, that's why I'm saying just delete that old code for EAcomp and MemAcc
because of all the CPU models use initiateAcc and completeAcc anyway...
On Tue, Mar 17, 2009 at 12:53 PM, Gabe Black gbl...@eecs.umich.edu wrote:
Korey Sewell wrote:
I theorize it hasn't come up, because the code isn't
I wouldn't mind those going since they're not even implemented in SPARC
or x86, but you can fix them if you use one InstObjParam for everything
in one instruction.
Gabe
Korey Sewell wrote:
Yea, that's why I'm saying just delete that old code for EAcomp and
MemAcc because of all the CPU models
How would you do that?
Can you give an example for the STQ:Alpha instruction.
The solution I have forces all the operands to be used, thus getting them
called in the correct order.
On Tue, Mar 17, 2009 at 1:01 PM, Gabe Black gbl...@eecs.umich.edu wrote:
I wouldn't mind those going since
I would be happy to, but I don't touch M5 code at work and I'm
spending all my other time with my family while they visit. If anyone
else wants to give it a shot that would be helpful.
Gabe
Quoting Korey Sewell ksew...@umich.edu:
How would you do that?
Can you give an example for the
2009/3/17 Korey Sewell ksew...@umich.edu:
I'd go with Active, Suspended, and Unallocated.
In my interpretation, the threads start in Suspended state because that
meant that you've allocated registers for that thread but it currently isn't
running. While Unallocated or Halted would mean that
changeset 9116be67b6d8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9116be67b6d8
description:
ply: put the absolute path to ply in the environment, not a relative one
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
SConstruct |2 +-
diffs (12 lines):
changeset 7e310503019e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7e310503019e
description:
includes: add ext to the includes path.
move dnet to the correct place so that we use this
diffstat:
30 files changed, 1738 insertions(+), 1738 deletions(-)
17 matches
Mail list logo
