If #2 didnt exist, then that would make more sense to me. That would make an
instruction HAVE to use the threadContext interface to access any CPU
facilities. That would also remove the CPU pointer from the instruction
object as well.
If that were the solution, I would be OK with it, because
I'm not sure I all the way understand why the register file shouldnt be
defined in the ISA...
I could see maybe there being one standard integer and floating point
register file thats totally generic however, the system/miscellaneous
registers are pretty ISA dependent so those register probably
I'm not sure I all the way understand why the register file shouldnt be
defined in the ISA...
I could see maybe there being one standard integer and floating point
register file thats totally generic however, the system/miscellaneous
registers are pretty ISA dependent so those register
Gabe,
I plan to work on developing WIKI documentation for the in-order model on
m5sim.org next week.
The short story is that the in-order model functions on three main concepts:
PipelineStage, Resource, and an Instruction Schedule.
- The Pipeline stage is a generic version of the pipeline stages
Instead of this, couldn't you do the cross thread thing by looking up
the appropriate thread context in the cpu object and then calling the
register access function for that thread context? This would work
more in line with the other CPU models.
I've been looking into this and it seems that
2009/2/13 Korey Sewell ksew...@umich.edu
Instead of this, couldn't you do the cross thread thing by looking up
the appropriate thread context in the cpu object and then calling the
register access function for that thread context? This would work
more in line with the other CPU models.
I haven't looked at this particular issue closely, but aren't you answering
your own question? The thing you gain by accessing the CPU via the
ThreadContext interface is that all of the CPU models present a consistent
and compatible interface to the instruction objects...
Hey Steve,
I agree
My toy example of this is say I want to read a integer register from an
instruction. I could either go:
(1) inst-threadContext-readIntReg()
or
(2) inst-cpu-readIntReg()
In the threadContext object, there is just some redundant call to
cpu-readIntReg() anyway. So you end up calling (1) and
If #2 didnt exist, then that would make more sense to me. That would make an
instruction HAVE to use the threadContext interface to access any CPU
facilities. That would also remove the CPU pointer from the instruction
object as well.
If that were the solution, I would be OK with it, because then
changeset 09ab46bfa914 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914
description:
InOrder: Import new inorder CPU model from MIPS.
This model currently only works in MIPS_SE mode, so it will take some
effort
to clean it up and make it
changeset 09ab46bfa914 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914
description:
InOrder: Import new inorder CPU model from MIPS.
This model currently only works in MIPS_SE mode, so it will take some
effort
to clean it up and make it
Thanks for the helping in pushing this out Nate.
There is a short and long version of the thread support in MIPS and why it
varies.
I'll give the short version here: MIPS was implemented ot use the MT ISA
extension
which requires the ability to read/write registers from other threads. I
designed
I'll give the short version here: MIPS was implemented ot use the MT ISA
extension
which requires the ability to read/write registers from other threads. I
designed the register file
to be on size fits all. It can be instantiated multiple times as a
per-thread register file (Simple-CPU) OR
13 matches
Mail list logo
