[m5-dev] thread context status
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 most transition to Active on cycle 1.
/// In MP or SMT systems, non-primary contexts will stay
/// in this state until a thread is assigned to them.
Unallocated,
/// Running. Instructions should be executed only when
/// the context is in this state.
Active,
/// Temporarily inactive. Entered while waiting for
/// synchronization, etc.
Suspended,
/// Permanently shut down. Entered when target executes
/// m5exit pseudo-instruction. When all contexts enter
/// this state, the simulation will terminate.
Halted
};
Those definitions seem reasonable, but the usage is very inconsistent.
Here are just a few things that appear to be happening:
- Though the SimpleCPU models follow the comments and initialize
threads in Unallocated, the O3 and InOrder CPUs initialize threads to
Suspended. I haven't tried this recently, but I recall that simply
changing the initialization code in O3 to start in Unallocated causes
other things to break.
- Even though the comment says that a thread in the Halted state is
permanently halted, the MIPS MT implementation appears to use this
state for something that looks more like a software-controlled
suspend.
- The Halted state is entered via some Alpha PAL instruction (maybe
cause by m5exit as the comment indicates), but an exit() call in SE
mode causes a thread to move back to Unallocated rather than Halted.
- The SPARC readFSReg function in ua2005.c looks like it is supposed
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).
- Other than the SPARC function mentioned above, I don't see anything
that ever looks to see if a thread is in the Halted state (i.e., it's
almost write-only).
It seems to me that we ought to be able to get away with just three states:
1. Active: no confusion there
2. Temporarily inactive (think paused)... what is basically
Suspended now, though I'm still confused about why InOrderCPU and O3
initialize threads to this state.
3. Stopped, basically combining both Halted and Unallocated.
The basic difference between #2 and #3 is that in #2 the thread
context has a software thread assigned to it but is just waiting to
resume execution, where in #3 there is no software thread assigned to
the context. I'm inclined to keep the Suspended and Halted names,
though this would be a good time to pick new ones if anyone felt that
would be helpful. (Particularly given that I expect the halt
instruction in x86 if not in other ISAs to actually move a thread to
Suspended rather than Halted, we may want to pick a different name for
state #3.)
I expect there's no way to really know whether a particular scheme
will work except to try it, but any comments or insight anyone could
provide up front would be helpful. I'm particularly curious about (1)
what if any semantics SPARC attributes to these various states based
on their exposure to software in the misc reg mentioned above and (2)
why it would matter that a CPU is initialized to Suspended rather than
Halted or Unallocated (since I know Gabe, Polina, and Ali have all
wrestled with this in FS mode recently).
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
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 passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. See /z/m5/regression/regress-2009-03-17-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] thread context status
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 in
/// this state, but most transition to Active on cycle 1.
/// In MP or SMT systems, non-primary contexts will stay
/// in this state until a thread is assigned to them.
Unallocated,
/// Running. Instructions should be executed only when
/// the context is in this state.
Active,
/// Temporarily inactive. Entered while waiting for
/// synchronization, etc.
Suspended,
/// Permanently shut down. Entered when target executes
/// m5exit pseudo-instruction. When all contexts enter
/// this state, the simulation will terminate.
Halted
};
Those definitions seem reasonable, but the usage is very inconsistent.
Here are just a few things that appear to be happening:
- Though the SimpleCPU models follow the comments and initialize
threads in Unallocated, the O3 and InOrder CPUs initialize threads to
Suspended. I haven't tried this recently, but I recall that simply
changing the initialization code in O3 to start in Unallocated causes
other things to break.
- Even though the comment says that a thread in the Halted state is
permanently halted, the MIPS MT implementation appears to use this
state for something that looks more like a software-controlled
suspend.
- The Halted state is entered via some Alpha PAL instruction (maybe
cause by m5exit as the comment indicates), but an exit() call in SE
mode causes a thread to move back to Unallocated rather than Halted.
- The SPARC readFSReg function in ua2005.c looks like it is supposed
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).
- Other than the SPARC function mentioned above, I don't see anything
that ever looks to see if a thread is in the Halted state (i.e., it's
almost write-only).
It seems to me that we ought to be able to get away with just three states:
1. Active: no confusion there
2. Temporarily inactive (think paused)... what is basically
Suspended now, though I'm still confused about why InOrderCPU and O3
initialize threads to this state.
3. Stopped, basically combining both Halted and Unallocated.
The basic difference between #2 and #3 is that in #2 the thread
context has a software thread assigned to it but is just waiting to
resume execution, where in #3 there is no software thread assigned to
the context. I'm inclined to keep the Suspended and Halted names,
though this would be a good time to pick new ones if anyone felt that
would be helpful. (Particularly given that I expect the halt
instruction in x86 if not in other ISAs to actually move a thread to
Suspended rather than Halted, we may want to pick a different name for
state #3.)
I expect there's no way to really know whether a particular scheme
will work except to try it, but any comments or insight anyone could
provide up front would be helpful. I'm particularly curious about (1)
what if any semantics SPARC attributes to these various states based
on their exposure to software in the misc reg mentioned above and (2)
why it would matter that a CPU is initialized to Suspended rather than
Halted or Unallocated (since I know Gabe, Polina, and Ali have all
wrestled with this in FS mode recently).
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
I think Ali was the one that implemented the SPARC register you ask
about in 1. The x86 halt instruction does put you into a suspended state
where you'll wake back up if you get an interrupt. Another item for your
list could be that some CPU models are unwilling to start a thread as
suspended. Your three state system seems like a better idea than the old
four state one.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] thread context status
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 for a particular thread.
So I actually think starting a thread as Suspended makes sense. Maybe a
better term would be Inactive since it would be everything that a Active
thread has save for it running on a CPU.
On Tue, Mar 17, 2009 at 3:37 AM, Gabe Black gbl...@eecs.umich.edu wrote:
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 in
/// this state, but most transition to Active on cycle 1.
/// In MP or SMT systems, non-primary contexts will stay
/// in this state until a thread is assigned to them.
Unallocated,
/// Running. Instructions should be executed only when
/// the context is in this state.
Active,
/// Temporarily inactive. Entered while waiting for
/// synchronization, etc.
Suspended,
/// Permanently shut down. Entered when target executes
/// m5exit pseudo-instruction. When all contexts enter
/// this state, the simulation will terminate.
Halted
};
Those definitions seem reasonable, but the usage is very inconsistent.
Here are just a few things that appear to be happening:
- Though the SimpleCPU models follow the comments and initialize
threads in Unallocated, the O3 and InOrder CPUs initialize threads to
Suspended. I haven't tried this recently, but I recall that simply
changing the initialization code in O3 to start in Unallocated causes
other things to break.
- Even though the comment says that a thread in the Halted state is
permanently halted, the MIPS MT implementation appears to use this
state for something that looks more like a software-controlled
suspend.
- The Halted state is entered via some Alpha PAL instruction (maybe
cause by m5exit as the comment indicates), but an exit() call in SE
mode causes a thread to move back to Unallocated rather than Halted.
- The SPARC readFSReg function in ua2005.c looks like it is supposed
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).
- Other than the SPARC function mentioned above, I don't see anything
that ever looks to see if a thread is in the Halted state (i.e., it's
almost write-only).
It seems to me that we ought to be able to get away with just three
states:
1. Active: no confusion there
2. Temporarily inactive (think paused)... what is basically
Suspended now, though I'm still confused about why InOrderCPU and O3
initialize threads to this state.
3. Stopped, basically combining both Halted and Unallocated.
The basic difference between #2 and #3 is that in #2 the thread
context has a software thread assigned to it but is just waiting to
resume execution, where in #3 there is no software thread assigned to
the context. I'm inclined to keep the Suspended and Halted names,
though this would be a good time to pick new ones if anyone felt that
would be helpful. (Particularly given that I expect the halt
instruction in x86 if not in other ISAs to actually move a thread to
Suspended rather than Halted, we may want to pick a different name for
state #3.)
I expect there's no way to really know whether a particular scheme
will work except to try it, but any comments or insight anyone could
provide up front would be helpful. I'm particularly curious about (1)
what if any semantics SPARC attributes to these various states based
on their exposure to software in the misc reg mentioned above and (2)
why it would matter that a CPU is initialized to Suspended rather than
Halted or Unallocated (since I know Gabe, Polina, and Ali have all
wrestled with this in FS mode recently).
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
I think Ali was the one that implemented the SPARC register you ask
about in 1. The x86 halt instruction does put you into a suspended state
where you'll wake back up if you get an interrupt. Another item for your
list could be that some CPU models are unwilling to start a thread as
suspended. Your three state system seems like a better idea than the old
four state one.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
[m5-dev] Isa_parser operands bug
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 address calculation for split memory access because the operand order gets confused. Consider, a store instruction wants to write to a register Ra and calculate the address from Rb + disp. If you have a EAComp that only executes the Rb+disp, what happens is you get something like this to read Rb: Rb = readIntRegOperand(this, 0) That's incorrect because Rb is actually operand 1 and Ra is operand 0. This caused some tricky faults that had my mind spinning for a second (I didnt BLOW up M5, it was just a smalll bug ... phe). The culprit of this error is isa_parser.py and how we define instructions. There is no particular binding that says Rb is the 2nd operand and Ra is the 1st operand so in any case where Rb wants to be used without Ra there is potential for some confusion there. Thankfully, most instruction objects simply declare all operands upfront and Ra gets used somehow so this never surfaces. To fix it fix it, I think there would be some heavy work to get everything straight (basically noting operand order for every instruction), so unless someone sees a big problem with the way we currently do things I propose just to get rid of split_accesses that expose this bug (previous email) and just note that this could be a problem if someone wants to try something tricky in the future. -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] thread context status
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 with it's own meaning
of Halt.
On Tue, Mar 17, 2009 at 8:43 AM, Korey Sewell ksew...@umich.edu wrote:
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 for a particular thread.
So I actually think starting a thread as Suspended makes sense. Maybe a
better term would be Inactive since it would be everything that a Active
thread has save for it running on a CPU.
On Tue, Mar 17, 2009 at 3:37 AM, Gabe Black gbl...@eecs.umich.edu wrote:
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 in
/// this state, but most transition to Active on cycle 1.
/// In MP or SMT systems, non-primary contexts will stay
/// in this state until a thread is assigned to them.
Unallocated,
/// Running. Instructions should be executed only when
/// the context is in this state.
Active,
/// Temporarily inactive. Entered while waiting for
/// synchronization, etc.
Suspended,
/// Permanently shut down. Entered when target executes
/// m5exit pseudo-instruction. When all contexts enter
/// this state, the simulation will terminate.
Halted
};
Those definitions seem reasonable, but the usage is very inconsistent.
Here are just a few things that appear to be happening:
- Though the SimpleCPU models follow the comments and initialize
threads in Unallocated, the O3 and InOrder CPUs initialize threads to
Suspended. I haven't tried this recently, but I recall that simply
changing the initialization code in O3 to start in Unallocated causes
other things to break.
- Even though the comment says that a thread in the Halted state is
permanently halted, the MIPS MT implementation appears to use this
state for something that looks more like a software-controlled
suspend.
- The Halted state is entered via some Alpha PAL instruction (maybe
cause by m5exit as the comment indicates), but an exit() call in SE
mode causes a thread to move back to Unallocated rather than Halted.
- The SPARC readFSReg function in ua2005.c looks like it is supposed
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).
- Other than the SPARC function mentioned above, I don't see anything
that ever looks to see if a thread is in the Halted state (i.e., it's
almost write-only).
It seems to me that we ought to be able to get away with just three
states:
1. Active: no confusion there
2. Temporarily inactive (think paused)... what is basically
Suspended now, though I'm still confused about why InOrderCPU and O3
initialize threads to this state.
3. Stopped, basically combining both Halted and Unallocated.
The basic difference between #2 and #3 is that in #2 the thread
context has a software thread assigned to it but is just waiting to
resume execution, where in #3 there is no software thread assigned to
the context. I'm inclined to keep the Suspended and Halted names,
though this would be a good time to pick new ones if anyone felt that
would be helpful. (Particularly given that I expect the halt
instruction in x86 if not in other ISAs to actually move a thread to
Suspended rather than Halted, we may want to pick a different name for
state #3.)
I expect there's no way to really know whether a particular scheme
will work except to try it, but any comments or insight anyone could
provide up front would be helpful. I'm particularly curious about (1)
what if any semantics SPARC attributes to these various states based
on their exposure to software in the misc reg mentioned above and (2)
why it would matter that a CPU is initialized to Suspended rather than
Halted or Unallocated (since I know Gabe, Polina, and Ali have all
wrestled with this in FS mode recently).
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
I think Ali was the one that implemented the SPARC register you ask
about in 1. The x86 halt
Re: [m5-dev] thread context status
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 bundled unallocated and halted together. - Other than the SPARC function mentioned above, I don't see anything that ever looks to see if a thread is in the Halted state (i.e., it's almost write-only). It seems to me that we ought to be able to get away with just three states: 1. Active: no confusion there 2. Temporarily inactive (think paused)... what is basically Suspended now, though I'm still confused about why InOrderCPU and O3 initialize threads to this state. 3. Stopped, basically combining both Halted and Unallocated. The basic difference between #2 and #3 is that in #2 the thread context has a software thread assigned to it but is just waiting to resume execution, where in #3 there is no software thread assigned to the context. I'm inclined to keep the Suspended and Halted names, though this would be a good time to pick new ones if anyone felt that would be helpful. (Particularly given that I expect the halt instruction in x86 if not in other ISAs to actually move a thread to Suspended rather than Halted, we may want to pick a different name for state #3.) I expect there's no way to really know whether a particular scheme will work except to try it, but any comments or insight anyone could provide up front would be helpful. I'm particularly curious about (1) what if any semantics SPARC attributes to these various states based on their exposure to software in the misc reg mentioned above and (2) why it would matter that a CPU is initialized to Suspended rather than Halted or Unallocated (since I know Gabe, Polina, and Ali have all wrestled with this in FS mode recently). There are different states as far as SPARC is concerned. I created a initCPU() function that all the ISAs execute at the beginning to do the correct thing for initialization. The Alpha CPUs start up immediately and start spinning at a known vector, while the SPARC ones wait for an explicit start IPI. I think the Unallocated state comes from SE mode, where you want to differentiate between a CPU that has done exit() and one that has never been used, however maybe that doesn't really matter. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 registers the InstObjParam knows about are coordinated so that instruction classes with different pieces in different templates are set up consistently. You might not be taking advantage of one of those but there could be a bug too. Gabe Korey Sewell wrote: 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 address calculation for split memory access because the operand order gets confused. Consider, a store instruction wants to write to a register Ra and calculate the address from Rb + disp. If you have a EAComp that only executes the Rb+disp, what happens is you get something like this to read Rb: Rb = readIntRegOperand(this, 0) That's incorrect because Rb is actually operand 1 and Ra is operand 0. This caused some tricky faults that had my mind spinning for a second (I didnt BLOW up M5, it was just a smalll bug ... phe). The culprit of this error is isa_parser.py and how we define instructions. There is no particular binding that says Rb is the 2nd operand and Ra is the 1st operand so in any case where Rb wants to be used without Ra there is potential for some confusion there. Thankfully, most instruction objects simply declare all operands upfront and Ra gets used somehow so this never surfaces. To fix it fix it, I think there would be some heavy work to get everything straight (basically noting operand order for every instruction), so unless someone sees a big problem with the way we currently do things I propose just to get rid of split_accesses that expose this bug (previous email) and just note that this could be a problem if someone wants to try something tricky in the future. -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. On Tue, Mar 17, 2009 at 12:28 PM, Gabe Black gbl...@eecs.umich.edu wrote: 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 registers the InstObjParam knows about are coordinated so that instruction classes with different pieces in different templates are set up consistently. You might not be taking advantage of one of those but there could be a bug too. Gabe Korey Sewell wrote: 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 address calculation for split memory access because the operand order gets confused. Consider, a store instruction wants to write to a register Ra and calculate the address from Rb + disp. If you have a EAComp that only executes the Rb+disp, what happens is you get something like this to read Rb: Rb = readIntRegOperand(this, 0) That's incorrect because Rb is actually operand 1 and Ra is operand 0. This caused some tricky faults that had my mind spinning for a second (I didnt BLOW up M5, it was just a smalll bug ... phe). The culprit of this error is isa_parser.py and how we define instructions. There is no particular binding that says Rb is the 2nd operand and Ra is the 1st operand so in any case where Rb wants to be used without Ra there is potential for some confusion there. Thankfully, most instruction objects simply declare all operands upfront and Ra gets used somehow so this never surfaces. To fix it fix it, I think there would be some heavy work to get everything straight (basically noting operand order for every instruction), so unless someone sees a big problem with the way we currently do things I propose just to get rid of split_accesses that expose this bug (previous email) and just note that this could be a problem if someone wants to try something tricky in the future. -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 are read in order The picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. I haven't looked at the code, but I'm betting these are generated with different InstObjParams which don't know about all the code snippets at once. A rule we added (and never wrote down as far as I know) is that you should use one InstObjParam with all the different pieces of code and then substitute it wherever it's needed. That was to fix a similar issue I was having with the SPARC split memory stuff. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 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 picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. I haven't looked at the code, but I'm betting these are generated with different InstObjParams which don't know about all the code snippets at once. A rule we added (and never wrote down as far as I know) is that you should use one InstObjParam with all the different pieces of code and then substitute it wherever it's needed. That was to fix a similar issue I was having with the SPARC split memory stuff. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 use initiateAcc and completeAcc anyway... On Tue, Mar 17, 2009 at 12:53 PM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: 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 are read in order The picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. I haven't looked at the code, but I'm betting these are generated with different InstObjParams which don't know about all the code snippets at once. A rule we added (and never wrote down as far as I know) is that you should use one InstObjParam with all the different pieces of code and then substitute it wherever it's needed. That was to fix a similar issue I was having with the SPARC split memory stuff. Gabe ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 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 use initiateAcc and completeAcc anyway... On Tue, Mar 17, 2009 at 12:53 PM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: 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 are read in order The picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. I haven't looked at the code, but I'm betting these are generated with different InstObjParams which don't know about all the code snippets at once. A rule we added (and never wrote down as far as I know) is that you should use one InstObjParam with all the different pieces of code and then substitute it wherever it's needed. That was to fix a similar issue I was having with the SPARC split memory stuff. Gabe ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Isa_parser operands bug
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 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 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 use initiateAcc and completeAcc anyway... On Tue, Mar 17, 2009 at 12:53 PM, Gabe Black gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote: 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 are read in order The picture is this for a STQ instruction for alpha: EA = Rb + disp Mem = Ra Normally, Ra is evaluated and assigned an operand before Rb (operands.isa) so when this code gets executed in initiateAcc(), so isa_parser.py:1668 contributes to this: Ra = readIntRegOperand(this, 0) Rb = readIntRegOperand(this, 1) Everything works fine. However, when you have the eaComp() split instruction then you only the ea-code snippet being generated: EA = Rb + disp So isa_parser.py:1668 processes the registers operands and assigns Rb to operand 0 since it's the only operand in the code snippet. Hence: Rb = readIntRegOperand(this, 0) Now, that you've read Rb with the wrong operand, bad stuff is going to happen which first and foremost results in bad TLB translation. I haven't looked at the code, but I'm betting these are generated with different InstObjParams which don't know about all the code snippets at once. A rule we added (and never wrote down as far as I know) is that you should use one InstObjParam with all the different pieces of code and then substitute it wherever it's needed. That was to fix a similar issue I was having with the SPARC split memory stuff. Gabe ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] thread context status
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 the CPU has no knowledge or register binding for a particular thread. So I actually think starting a thread as Suspended makes sense. Maybe a better term would be Inactive since it would be everything that a Active thread has save for it running on a CPU. Actually I think that part of the problem we have now is that there isn't enough (or any?) separation between the ThreadContext-level thread status, which is primarily the software's view of the thread state, and the microarchitectural view, specifically in O3. There's really no requirement that there be any microarchitectural change in register bindings once a thread enters the unallocated state; that's a microarchitectural policy decision. In fact it sounds like there's some confusion over the word unallocated even; it's intended to mean that the SW hasn't allocated this thread context to a task yet, which (again) is somewhat independent of whether the microarchitecture has allocated resources to the thread context. Similarly I would want Suspended to mean that the thread was suspended through some direct software action, like the HLT or MWAIT instruction, while a purely microarchitectural suspended state (e.g., because the thread is stalled on a long-latency memory operation) would be reflected only in the CPU model's internal data structures. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: ply: put the absolute path to ply in the enviro...
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):
diff -r 4df1c7698e52 -r 9116be67b6d8 SConstruct
--- a/SConstructMon Mar 16 15:16:58 2009 -0700
+++ b/SConstructTue Mar 17 12:45:41 2009 -0700
@@ -374,7 +374,7 @@
Export('extras_dir_list')
# M5_PLY is used by isa_parser.py to find the PLY package.
-env.Append(ENV = { 'M5_PLY' : str(Dir('ext/ply')) })
+env.Append(ENV = { 'M5_PLY' : Dir('ext/ply').abspath })
CXX_version = read_command([env['CXX'],'--version'], exception=False)
CXX_V = read_command([env['CXX'],'-V'], exception=False)
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: includes: add ext to the includes path.
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(-)
SConstruct |4
ext/dnet/addr.h | 67 ++
ext/dnet/arp.h | 103 +
ext/dnet/blob.h | 56 +
ext/dnet/dnet/addr.h| 67 --
ext/dnet/dnet/arp.h | 103 -
ext/dnet/dnet/blob.h| 56 -
ext/dnet/dnet/eth.h | 77 ---
ext/dnet/dnet/fw.h | 54 -
ext/dnet/dnet/icmp.h| 265 -
ext/dnet/dnet/intf.h| 68 --
ext/dnet/dnet/ip.h | 487 ---
ext/dnet/dnet/ip6.h | 183 -
ext/dnet/dnet/os.h | 117 ---
ext/dnet/dnet/rand.h| 33 ---
ext/dnet/dnet/route.h | 35 ---
ext/dnet/dnet/tcp.h | 158 ---
ext/dnet/dnet/udp.h | 32 ---
ext/dnet/eth.h | 77 +++
ext/dnet/fw.h | 54 +
ext/dnet/icmp.h | 265 +
ext/dnet/intf.h | 68 ++
ext/dnet/ip.h | 487 +++
ext/dnet/ip6.h | 183 +
ext/dnet/os.h | 117 +++
ext/dnet/rand.h | 33 +++
ext/dnet/route.h| 35 +++
ext/dnet/tcp.h | 158 +++
ext/dnet/udp.h | 32 +++
ext/gzstream/SConscript |2
diffs (truncated from 3615 to 300 lines):
diff -r 9116be67b6d8 -r 7e310503019e SConstruct
--- a/SConstructTue Mar 17 12:45:41 2009 -0700
+++ b/SConstructTue Mar 17 12:49:03 2009 -0700
@@ -373,6 +373,9 @@
Export('base_dir')
Export('extras_dir_list')
+# the ext directory should be on the #includes path
+env.Append(CPPPATH=[Dir('ext')])
+
# M5_PLY is used by isa_parser.py to find the PLY package.
env.Append(ENV = { 'M5_PLY' : Dir('ext/ply').abspath })
@@ -418,7 +421,6 @@
if sys.platform == 'cygwin':
# cygwin has some header file issues...
env.Append(CCFLAGS=Split(-Wno-uninitialized))
-env.Append(CPPPATH=[Dir('ext/dnet')])
# Check for SWIG
if not env.has_key('SWIG'):
diff -r 9116be67b6d8 -r 7e310503019e ext/dnet/addr.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/ext/dnet/addr.h Tue Mar 17 12:49:03 2009 -0700
@@ -0,0 +1,67 @@
+/*
+ * addr.h
+ *
+ * Network address operations.
+ *
+ * Copyright (c) 2000 Dug Song dugs...@monkey.org
+ *
+ * $Id: addr.h,v 1.12 2003/02/27 03:44:55 dugsong Exp $
+ */
+
+#ifndef DNET_ADDR_H
+#define DNET_ADDR_H
+
+#define ADDR_TYPE_NONE 0 /* No address set */
+#defineADDR_TYPE_ETH 1 /* Ethernet */
+#defineADDR_TYPE_IP2 /* Internet Protocol v4 */
+#defineADDR_TYPE_IP6 3 /* Internet Protocol v6 */
+
+struct addr {
+uint16_t addr_type;
+uint16_t addr_bits;
+union {
+eth_addr_t __eth;
+ip_addr_t __ip;
+ip6_addr_t __ip6;
+
+uint8_t__data8[16];
+uint16_t __data16[8];
+uint32_t __data32[4];
+} __addr_u;
+};
+#define addr_eth __addr_u.__eth
+#define addr_ip__addr_u.__ip
+#define addr_ip6 __addr_u.__ip6
+#define addr_data8 __addr_u.__data8
+#define addr_data16__addr_u.__data16
+#define addr_data32__addr_u.__data32
+
+#define addr_pack(addr, type, bits, data, len) do {\
+(addr)-addr_type = type; \
+(addr)-addr_bits = bits; \
+memmove((addr)-addr_data8, (char *)data, len);\
+} while (0)
+
+__BEGIN_DECLS
+int addr_cmp(const struct addr *a, const struct addr *b);
+
+int addr_bcast(const struct addr *a, struct addr *b);
+int addr_net(const struct addr *a, struct addr *b);
+
+char *addr_ntop(const struct addr *src, char *dst, size_t size);
+int addr_pton(const char *src, struct addr *dst);
+
+char *addr_ntoa(const struct addr *a);
+#define addr_aton addr_pton
+
+int addr_ntos(const struct addr *a, struct sockaddr *sa);
+int addr_ston(const struct sockaddr *sa, struct addr *a);
+
+int addr_btos(uint16_t bits, struct sockaddr *sa);
+int addr_stob(const struct sockaddr *sa, uint16_t *bits);
+
+int addr_btom(uint16_t bits, void *mask, size_t size);
+int addr_mtob(const void *mask, size_t size, uint16_t *bits);
+__END_DECLS
+
+#endif /* DNET_ADDR_H */
diff -r 9116be67b6d8 -r 7e310503019e ext/dnet/arp.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/ext/dnet/arp.hTue Mar 17 12:49:03 2009 -0700
@@ -0,0 +1,103 @@
+/*
+ * arp.h
+ *
+ * Address Resolution Protocol.
+ * RFC 826
+ *
+ * Copyright (c) 2000 Dug Song dugs...@monkey.org
+ *
+ * $Id: arp.h,v
