I cloned a fresh M5 out the repo and I'm trying to build
ALPHA_SE/AtomicSimpleCPU M5 in Cygwin and I get the following error:
g++ -o build/ALPHA_SE/python/swig/core_wrap.do -c -pipe
-fno-strict-aliasing -Wall -Wno-sign-compare -Werror -Wundef
-Wno-uninitialized -ggdb3 -DTHE_ISA=ALPHA_ISA -DDEBUG
I sort of started adding Extending M5 tutorials in the documentation
on the WIKI page a while back so people can see how easy the
extension
capabilities of M5 are ( Making Your Own ISA/CPU Model)
However, i also think it would very cool if we have some example
scripts (and tutorials using those
Yea, it should definitely be a parameter... maybe a system parameter
rather than a workload parameter though (since in multi-programmed workloads
you actually have multiple workload objects).
I actually spoke to soon about this fix. Right now, I'm going through a
bunch of minor changes that
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1208683770 14400
# Node ID b5b48894da50df7ad59f94044d2f47e8fb4737d7
# Parent e4987b6ca365d53bf2d66c986db918ce48d589b0
Exit in SE mode when all threads are done running.
diff -r e4987b6ca365 -r b5b48894da50 src/cpu/base.cc
--- a/src/cpu/base.cc
I'm not sure how useful it would be to the world, but in
implementing the Mixie/flexible model I edited ExecTrace so that it
kept track of when a instruction entered each stage. This way, when a
instruction executed it would:
#1 be in-order of commit
#2 the stalls between stages could be more
how long has SMT regressions been broke? Is this a new thing?
I havent looked at O3 SMT in awhile, but I would assume the O3 changes
over the past year or so take my fix time way up!
Is there a particular changeset or marker where we can say it broke here...?
On Sat, Sep 6, 2008 at 1:25 PM,
alright, i'll dig a little and see what's up.
On Mon, Sep 8, 2008 at 10:27 AM, nathan binkert [EMAIL PROTECTED] wrote:
how long has SMT regressions been broke? Is this a new thing?
I havent looked at O3 SMT in awhile, but I would assume the O3 changes
over the past year or so take my fix time
How's it a compiler error to do a unsigned integer comparison?
In the MIPS ISA, I believe a bunch of registers were added into int reg.
file to maintain add in the MIPS MT /DSP compatibility.
However, this looks to be some shadow set register compatibility code that
got added...
On Wed, Sep 24,
oh i think I see now...
This shadow set code and DSP/MT was done by myself and some of the MIPS
guys...
Anyway, the issue is probably that the value for NumShadowSets or
something is set to 0 or a wrong value causing the bad access.
I'll see if I can look into it...
But this is an actual
Yea, I think there might be a fix for thatin the patch that I sent
did it have any of the arch/mips/isa files?
I did change some stuff in there to get the memory system to function
correctly with M5, because in the Mixie model you need to be able to
have a memory operation happen in a
OK, so I agree that the else clause is looking superfluous and with
the comment probably written by ... then it definitely has no place.
So if the compiler warning is caused by writing past the out of bounds
value then the fix would be to just delete the else clause since
inside of the original
Looking further, it seems that there has been confusion on NumIntRegs
v. NumArchIntRegs on Jaidev's implementation.
Wrgpr and Rdgpr are functions for the sole purpose of having shadow
set register compatibility.
Those functions need to take whatever the source register value and
then use a
Can we talk to Jaidev? Do you have his e-mail address?
Sure, I can email him...
I'd like to
get this figured out. Do they have updated code perhaps?
I'm pretty sure that is the appropriate fix. Full coverage of the
shadow-sets in regression testing wasnt available previously so like I
said
is the patch that should be good to go...
On Wed, Oct 1, 2008 at 5:00 PM, nathan binkert [EMAIL PROTECTED] wrote:
Any update on a diff korey? We need to get this done and out the door.
Nate
On Tue, Sep 30, 2008 at 10:07 AM, Korey Sewell [EMAIL PROTECTED] wrote:
Can we talk to Jaidev? Do you have his
register flattening rather than the instruction itself to get the right
set of registers, and then you'd use indices outside the normal range to
get the flattening code to give you an index in the right bank.
Gabe
Korey Sewell wrote:
Implementing shadow sets for the rdpgpr and wrpgpr is going
Nate
On Fri, Oct 24, 2008 at 2:50 PM, Korey Sewell [EMAIL PROTECTED] wrote:
I do think a thread ID per core is necessary as you need to give OS's
the ability to assign to a specific thread in a core and not treat all
SMT cores as a separate CPU in every case.
On Fri, Oct 24, 2008 at 5:47 PM
CPU to
linux. Any actual coreID (maybe that's a better name) or cpuID or
threadID would be only used in the simulator
Nate
On Fri, Oct 24, 2008 at 2:50 PM, Korey Sewell [EMAIL PROTECTED]
wrote:
I do think a thread ID per core is necessary as you need to give OS's
the ability
Is that code not in all of the other completeAcc ISA functions?
On Sat, Nov 8, 2008 at 10:20 PM, Gabe Black [EMAIL PROTECTED] wrote:
I'm sure we could. This is useful anywhere you need to get an endian
converted value out of a packet without knowing the size ahead of time.
Does that happen
1st import
___
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
# HG changeset patch
# User Korey Sewell [EMAIL PROTECTED]
# Date 1227564379 18000
# Node ID 749752ee7d161ae2791a81c93c126351179469e3
# Parent b2b20a241e923c43a6978ea42fab9be4ead71220
[mq]: fix_mixie_per_stage_tracing
diff -r b2b20a241e92 -r 749752ee7d16 src/cpu/exetrace.cc
--- a/src/cpu
# HG changeset patch
# User Korey Sewell [EMAIL PROTECTED]
# Date 1227320916 18000
# Node ID b2b20a241e923c43a6978ea42fab9be4ead71220
# Parent 6f9923f77ced7b25a7a573549fd4ca1b0a49c466
[mq]: make_mixie_cmdline_runnable
diff -r 6f9923f77ced -r b2b20a241e92 configs/common/Options.py
--- a/configs
, specifically the lines with cout and the commented out lines. Also,
please try not to leave small whitespace changes in there.
Gabe
Quoting Korey Sewell [EMAIL PROTECTED]:
# HG changeset patch
# User Korey Sewell [EMAIL PROTECTED]
# Date 1227320916 18000
# Node ID
On the comment thing, I'm saying I realized too late that I had two
distinct changes in one patch, so took the shortcut of commenting out
one so I could have a separate patch with the diff. change.
On Mon, Nov 24, 2008 at 11:11 PM, Gabe Black [EMAIL PROTECTED] wrote:
Korey Sewell wrote:
How
then override the default
tracer your CPU class uses to be the one that does whatever special thing you
want. The class that keeps track of the execution of a particular instruction
is extensible as well if you want to add new fields, etc.
Gabe
Quoting Korey Sewell [EMAIL PROTECTED]:
# HG
/if you're queue is in a
repository. I've had my pending x86 patches on m5sim.org for a while now
if you want to see an example, although I don't think they show up in
the web interface.
Gabe
Korey Sewell wrote:
If you get a chance, look at that closely.
I do derive a new tracer from
! BUT a good reminder to
not make that mistake again.
2008/11/30 Lisa Hsu [EMAIL PROTECTED]:
i would imagine you need to do patch -p1, not -p0. what errors do you get
when your patching fails?
lisa
On Sun, Nov 30, 2008 at 4:25 PM, Korey Sewell [EMAIL PROTECTED] wrote:
i'm having a problem
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1229550124 18000
# Node ID dd8d283a7f51ea568db6662d307462f273167dfa
# Parent 3d86004eff5b5725329c755910c43d3e4c72fecb
[mq]: ioctl_linux_call
diff -r 3d86004eff5b -r dd8d283a7f51 src/arch/mips/linux/linux.hh
--- a/src/arch/mips
For some reason, these constants didnt get updated for MIPS Linux, which is
causing Hello World not to get work when TraceFlags were on...
On Wed, Dec 17, 2008 at 4:46 PM, Korey Sewell ksew...@eecs.umich.eduwrote:
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1229550124
Gabe,
Can you step-by-step explain what's inaccurate about the current TLB
process?
On Wed, Jan 14, 2009 at 6:31 PM, gbl...@eecs.umich.edu wrote:
Has anyone had a chance to give this some thought? Could Kevin/Korey
comment on
how hard they think it would be and/or how much overhead there
Quoting Korey Sewell ksew...@umich.edu:
Gabe,
Can you step-by-step explain what's inaccurate about the current TLB
process?
On Wed, Jan 14, 2009 at 6:31 PM, gbl...@eecs.umich.edu wrote:
Has anyone had a chance to give this some thought? Could Kevin/Korey
comment on
how hard
Isn't before it commits the same as before/while it's executing?
On Sat, Jan 17, 2009 at 1:35 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I don't think that'll work because the fix up needs to happen
before/while the instruction executes, not on the side before it commits.
Korey Sewell wrote
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1231782856 18000
# Node ID 24fa73b990faa412fcf649a6ed8e2234e53dd160
# Parent 3fca4a3af17382af709dff051487aa4aa0538362
imported patch update_memAccFlags_return_type
diff -r 3fca4a3af173 -r 24fa73b990fa src/cpu/static_inst.hh
bug fixes in up front. For example there's one patch that
introduces a memAccFlags() method that returns unsigned, then another patch
that fixes the return value to Request::Flags... why not just import it
right in the first place.
Steve
On Sat, Jan 17, 2009 at 7:44 AM, Korey Sewell ksew
also like to change the name from
mixie to inorder. Those are two things I can do if you give me a few
hours to own your patches.
Nate
2009/1/17 Korey Sewell ksew...@umich.edu:
Thanks Steve,
looks like I have some re-work todo.
My original repo got corrupted when I try to pull
I put the in-order mixie patches on m5sim.org so that if any wants,
they can assist in the effort of cleaning things and officially
integrating the CPU model.
You should be able to clone the patch repo at:
daystrom.m5sim.org//repo/inorder-patches
Using the patches and the series file, people
- Since this is mostly a big import anyway, I'd favor integrating all the
outstanding bug fixes in up front.
So are you saying that it would be best to get all the license fixes,
commented code, whitespace, etc. cleaned up and then
integrate that into just one BIG patch?
If so, I do see your
Hi Gabe,
I just wanted to chime in and say good work! I'm sure lots of people will
benefit from your x86 efforts so you should feel very good about yourself!
On Wed, Feb 4, 2009 at 3:07 PM, gbl...@eecs.umich.edu wrote:
Even if people wouldn't normally run init (the scripts, not /sbin/init I'm
changeset 54ed46881217 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=54ed46881217
description:
CPU: Prepare CPU models for the new in-order CPU model.
Some new functions and forward declarations are necessary to make
things work
diffstat:
3 files changed, 17
changeset 303e409d88d9 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=303e409d88d9
description:
ExeTrace: Allow subclasses of the tracer to define their own prefix to
dump
diffstat:
2 files changed, 8 insertions(+), 1 deletion(-)
src/cpu/exetrace.cc |8 +++-
changeset c3e4371d37a8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c3e4371d37a8
description:
syscall: Expose ioctl for MIPS
diffstat:
2 files changed, 10 insertions(+), 10 deletions(-)
src/arch/mips/linux/linux.hh | 18 +-
IN CONTRACT, STRICT LIABILITY, OR TORT
+# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+# Authors: Korey Sewell
+
+from m5.params import *
+from m5.proxy import *
+from m5 import build_env
+from BaseCPU
changeset acbe11bbfe68 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=acbe11bbfe68
description:
Configs: Add support for the InOrder CPU model
diffstat:
6 files changed, 174 insertions(+), 151 deletions(-)
configs/common/Options.py |1
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
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
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
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
Hey all,
I am currently unable to build any CPU Model successfully after the scons
update...0
Other people seem to be doing just fine, so am I missing something?
My error message has something to do with generating a defines.py file:
makeDefinesPyFile([build/ALPHA_SE/python/m5/defines.py],
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 know nobody likes to read looong emails so I'll try to help in splitting
this up this email into 2 parts:
1. Comments on Gabe's idea
2. My proposed solution
=== Comments on Gabe's Idea ===
From what I gather from Gabe's writeup, I would say the quick/dirty of what
Gabe wants to do is decouple
Comments on this:
- Would we need a separate per-core object for core-wide ISA-specific
state? I'm guessing we might.
We might. There's no such thing right now that jumps to mind. I remember
there being some ambiguity with SPARC where some state might have been
for all threads in a core. I
looking in src/cpu/inorder/SConstruct, I see that the inorder model
wants to compile these files from O3:
Source('../o3/btb.cc')
Source('../o3/tournament_pred.cc')
Source('../o3/2bit_local_pred.cc')
Source('../o3/free_list.cc')
Source('../o3/rename_map)
Of
typo:
*SConscript
AND
there is a TraceFlag('FreeList') in there that can be whacked as well.
On Fri, Feb 20, 2009 at 9:00 AM, Korey Sewell ksew...@umich.edu wrote:
looking in src/cpu/inorder/SConstruct, I see that the inorder model
wants to compile these files from O3:
Source('../o3
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1235138771 18000
# Node ID b6e4240c46e429bf99fefd0d61fef1465de86e49
# Parent 7a74edaa8741dd7fb541ef6d404dac3a9ebc86f9
imported patch inorder-alpha-port
diff -r 7a74edaa8741 -r b6e4240c46e4 src/arch/SConscript
--- a/src/arch
is per-Thread and if so, use that thread ID to access
the right register.
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
On Fri, Feb 20, 2009 at 9:27 AM, Korey Sewell ksew...@eecs.umich.edu wrote:
# HG changeset patch
# User
changeset 6fd7648e1b8d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6fd7648e1b8d
description:
Remove unnecessary building of FreeList/RenameMap in InOrder. Clean-up
comments and O3 extensions InOrder Thread Context
diffstat:
5 files changed, 4 insertions(+), 111
:46 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Why is the in order model asking for O3 source files to be compiled in
the first place?
Gabe
Quoting Korey Sewell ksew...@umich.edu:
changeset 6fd7648e1b8d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node
oooph...32/4 =8...8 bits in a byte...I plead the 5th!
Originally, that code came from trying to align with some of the SPARC
generic constants (SingleWidth) and I got a little too cute trying to
define a SingleBytes.
And since no ALPHA or MIPS code depends on SingleBytes that's probably
why that
I'm a little unsure of what you are saying here Nate.
I am trying to add a mt.hh for ALPHA (so it can use the InOrder model)
but through some fault of mines the alpha version of the mt.hh file
got omitted.
Eventually, any ISA wanting to use InOrder would need to at the very
least have some bare
So one of my M5 sims failed recently and provided this message:
For more information see: http://www.m5sim.org/fatal/5c55a396;
I saw a thread on this not so far back, but could not find it in my
Inbox now that I actually want to check it out (just my luck,
right?)...
Can someone give me a quick
...@umich.edu wrote:
Take a look at one of the mailing list archives.
Ali
On Feb 23, 2009, at 11:51 PM, Korey Sewell wrote:
So one of my M5 sims failed recently and provided this message:
For more information see: http://www.m5sim.org/fatal/5c55a396;
I saw a thread on this not so far back, but could
I'm not seeing that thread in the archives...(no mail list search feature)?
anybody recall the subject line there?
On Mon, Feb 23, 2009 at 11:58 PM, Ali Saidi sa...@umich.edu wrote:
Take a look at one of the mailing list archives.
Ali
On Feb 23, 2009, at 11:51 PM, Korey Sewell wrote:
So
Hey Gabe,
why did we make the switch from ArgumentReg array to argument names?
Just wondering.
On Fri, Feb 27, 2009 at 12:37 PM, Gabe Black gbl...@eecs.umich.edu wrote:
changeset 4270e0502e5e in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=4270e0502e5e
Nate,
are you referring to the CPU's state vs. the actual thread-object's state?
That connection between the two in my opinion has been ad-hoc for
awhile or at least beyond my complete understanding.
Changing things for FS breaks SE and vice-versa.
Needless to say, we should probably get this
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1236007007 18000
# Node ID 9a2e4b6c275a8513f040d4cb7604b2f8f25aeb68
# Parent bcb6c464587b1ef278165ff41442b226fed2a4a9
InOrder didnt have all it's params set to a default value, which is now
required for M5 objects; Also
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1236007009 18000
# Node ID 2c4821af1e8314377232578e7aa72177bad27761
# Parent 9a2e4b6c275a8513f040d4cb7604b2f8f25aeb68
make handling of interstage buffers (i.e. StageQueues) more consistent:
(1)number from 0-n, not 1-n+1, (2
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1236007006 18000
# Node ID bcb6c464587b1ef278165ff41442b226fed2a4a9
# Parent 8340f7c1862ea4bcb29e6e018dbdb8ae19b282ce
Give TimeBuffer an ID that can be set. Necessary because InOrder uses generic
stages so w/o an ID
, 2009 at 7:58 AM, Korey Sewell ksew...@eecs.umich.edu wrote:
# HG changeset patch
# User Korey Sewell ksew...@umich.edu
# Date 1236007006 18000
# Node ID bcb6c464587b1ef278165ff41442b226fed2a4a9
# Parent 8340f7c1862ea4bcb29e6e018dbdb8ae19b282ce
Give TimeBuffer an ID that can be set
changeset 2a2c2403ee5b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2a2c2403ee5b
description:
use numCycles instead of simTicks to determine CPI stat in InOrder
diffstat:
1 file changed, 2 insertions(+), 2 deletions(-)
src/cpu/inorder/cpu.cc |4 ++--
diffs (21
changeset 4842a7d78634 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4842a7d78634
description:
Give TimeBuffer an ID that can be set. Necessary because InOrder uses
generic stages so w/o an ID there is no way to differentiate buffers when
debugging
diffstat:
3
changeset b4e30b30f695 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=b4e30b30f695
description:
InOrder didnt have all it's params set to a default value, which is now
required for M5 objects; Also, a # of values need to be reset to 0 (or the
appropriate value) before
changeset a6d07755d34f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a6d07755d34f
description:
make handling of interstage buffers (i.e. StageQueues) more consistent:
(1)number from 0-n, not 1-n+1, (2) always check nextStageValid before a
stageNum+1 and
changeset a87880065b42 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a87880065b42
description:
Remove unused functions/comments cluttering up the code.
diffstat:
13 files changed, 14 insertions(+), 159 deletions(-)
src/cpu/inorder/SConscript |2 -
changeset 38e32429b739 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=38e32429b739
description:
Give each resource in InOrder it's own TraceFlag instead of just
standard 'Resource' flag
diffstat:
11 files changed, 87 insertions(+), 77 deletions(-)
InOrderDynInst::InOrderDynInst()
: traceData(NULL), cpu(cpu)
-{ initVars(); }
+{
+seqNum = 0;
+initVars();
+}
Sorry guys, I'm aware of this... Constructor initialization will be updated
in next changeset. I want to go through all the InOrderCPU structures and
clean up any
changeset 4ed2100efa84 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4ed2100efa84
description:
InOrderCPU: Clean up Constructors to initialize variables correctly
(i.e. in a way for the compiler to play *nice*)
diffstat:
11 files changed, 33 insertions(+), 66
I believe the reason the UTB thing was done in that way was to try to match
the current M5 infrastructure which require ITB and DTB pointers in every
CPU model and have a few functions that hardcode (itb-___ or dtb-___).
If you dont derive UTB from both ITB and DTB you'll have a problem there
OK,
so the solution should probably be move the ITB/DTB functions into one base
TLB and then let a unified TLB derive off of that...correct?
This would allow us the two standard ITB and DTB pointers we've been
using...but also avoid multiple inheritance issues as well.
On Fri, Mar 6, 2009 at
Gabe,
aren't those per-CPU python parameters? In other words, each CPU
instantiates it' own set of parameters in the config file through this
python interface...right?
On Fri, Mar 6, 2009 at 3:09 AM, Gabe Black gbl...@eecs.umich.edu wrote:
Is the following correct? This is in the BaseCPU where
Nate,
I didn't directly implement that UTB part myself but I believe the mips utlb
has some different features than a normal tlb which allows them to share one
structure. I think that's part of their claim to fame so to speak...
Unfortunately, I can't think of the exact mechanism right now, but
That may be true, but none of it is actually in the UTB that we have
in our tree. All the UTB does is inherit from DTB and ITB and that's
it.
Although the UTB inheriting from the DTB and ITB seems pointless from the
outset, the way it was implemented is that if you can combine the
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
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
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
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
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
- In saying we should wack EAComp and MemAcc, I neglected to mention my
solution which was to create another function similar to initiateAcc and
completeAcc called addrGen which basically does what EAComp does but
doesnt write back the memory_access code but ensured the write operands
would get
The only compelling reason I see to avoid initateAcc() is if for some
reason the input operands for the EA calculation were no longer
available at that point in the pipeline.
It's a possible optimization that you could early release a source register
after it's already been used to calculate
Yes, that's exactly my point. I'm proposing that we do it all through
functions and get rid of the subinstructions. I'm trying to figure
out if the subinstructions are actually buying us anything that we
need at this point.
Well, other than provide a easy/proven way to read only the
I would echo Gabe sentiments. I've been suspicious of the trace-flags
causing memory corruption for awhile now, but every time I dig into it
there's some small error that I'm propagating through that finally surfaces.
In the big picture, I suspect that the trace-flags just exacerbate any kind
of
Hi, thanks for your interest in M5. I'd be happy to assist with solving some
of these problems as updating and committing regressions for the MIPS O3
model has long been overdue on my part. I actually believed that we had
fixed this earlier so I was a bit surprised to see this same error.
For
For the TLB changes,
can someone elaborate on what the 3 modes mean {Read, Write, Execute}?
I ask because in the translateAtomic function it seems as if the only modes
that matter are Write and Execute. Why does Read not matter?
I might be missing something simple, but it seems as if there are
oohhh, wow
ok, yea, I just misread the code then. That's *just* the default value. I
knew something just wasn't right there in how I was looking at it.
The other issue I had was from the write value and confusing that with the
mode derived from the system register in the
If I would like to add a new regression test for the InOrder model what are
the steps? The WIKI entry I wrote is painfully outdated.
So far, I've collected the stats from m5.fast placed them in the correct
folder (quick/hello/ref/inorder-timing).
What do I need to to get M5 to recognize this
n/mJust took a little digging
If anyone wants to do this, you need to look in the m5/tests/SConscript file
and add your CPU-model to the script toward the bottom around line 265...
On Thu, Apr 9, 2009 at 12:54 PM, Korey Sewell ksew...@umich.edu wrote:
If I would like to add a new
for the help. The sooner I can get a hold of this the sooner I can
get stuff I've worked on 'stable' in the tree.
-Korey
On Thu, Apr 9, 2009 at 8:50 PM, Korey Sewell ksew...@umich.edu wrote:
n/mJust took a little digging
If anyone wants to do this, you need to look in the m5/tests
; it will just print out the result of the
last run if it thinks it's up to date. To force the test to be run you have
to delete all the files in the test dir (under build/*/tests).
Steve
On Thu, Apr 9, 2009 at 8:31 PM, Korey Sewell ksew...@umich.edu wrote:
OK, so I still have a few more questions
- port alpha to inorder model
- fix functionality to handle non-delay slot ISA
- add hello regression test as a start toward stabilizing the model
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
1 - 100 of 569 matches
Mail list logo
