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 wrote:
> changeset 4270e0502e5e in /z/repo/encumbered
> details: http://repo.m5sim.org/encumbered?cmd=changeset;node=4270e0502e5e
> summary: CPU: Stop using
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 st
Updates to InOrder Model; MIPS *was* slightly broken after import
==
-Of note is that I needed to an ID to the timebuffer class so that generic
pipeline stages could figure out what timebuffer they were accessing.
-Updated defaults in InOrder as newer changes forced param values to have a
def
# HG changeset patch
# User Korey Sewell
# Date 1236007005 18000
# Node ID 8340f7c1862ea4bcb29e6e018dbdb8ae19b282ce
# Parent 5e7899a2692f4b048620400643d320817af20624
use numCycles instead of simTicks to determine CPI stat in InOrder
diff -r 5e7899a2692f -r 8340f7c1862e src/cpu/inorder/cpu.cc
# HG changeset patch
# User Korey Sewell
# 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, a # of values need
# HG changeset patch
# User Korey Sewell
# 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) always check
# HG changeset patch
# User Korey Sewell
# Date 1236007011 18000
# Node ID 83adb3fded0dc5a2c0667609d5e4392440181bed
# Parent 2c4821af1e8314377232578e7aa72177bad27761
Remove un-used functions/comments cluttering up the code.
diff -r 2c4821af1e83 -r 83adb3fded0d src/cpu/inorder/SConscript
--- a
# HG changeset patch
# User Korey Sewell
# 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 there is no way to
.
>
> Nate
>
> On Mon, Mar 2, 2009 at 7:58 AM, Korey Sewell wrote:
>> # HG changeset patch
>> # User Korey Sewell
>> # Date 1236007006 18000
>> # Node ID bcb6c464587b1ef278165ff41442b226fed2a4a9
>> # Parent 8340f7c1862ea4bcb29e6e018dbdb8ae19b282ce
>>
Good catch. I'll go through and make sure this is done throughout the
model before commit...
On Mon, Mar 2, 2009 at 12:18 PM, nathan binkert wrote:
>> @@ -53,6 +53,15 @@ struct InterStageStruct {
>> uint64_t nextPC;
>> InstSeqNum squashedSeqNum;
>> bool includeSquashInst;
>> +
>> +
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 li
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 files
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 prevStageValid
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 -
src/
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(-)
src/cpu/inorder/SCon
>
> 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
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 deletio
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
wi
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 2:12
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 wrote:
> Is the following correct? This is in the BaseCPU where it sets up the
> data
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
functi
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
I would like to delete some code that has caused me confusion for awhile and
it seems its not even used anymore.
In the mem.isa files, two instruction objects EAComp and MemAcc are added to
each memory instruction. These can be referenced by the eaCompPtr() and
memAccPtr() in the instruction objec
>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 addres
t web with it's own meaning
of Halt.
On Tue, Mar 17, 2009 at 8:43 AM, Korey Sewell 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
Param 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 previou
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 wrote:
> Korey Sewell wrote:
> > I theorize it hasn't come up, because the c
7;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
- 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 g
>
> 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 calcula
>
> 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 r
Looks like a few of these issues are up my alley. I've been out of town for
the weekend, so I will take a strong look at these after I get back tonight.
On a first look, I'm thinking that the "activateWhenReady" code could be
safely removed since individual threads changing from active to unalloc
Comments below:
> The other place it's called though is in
> InOrderThreadContext::setThreadRescheduleCondition, a function that
> doesn't appear to be called from anywhere itself, so it's hard to say
> what it's supposed to be doing.
That function is supposed to be called from arch/mips/mt.hh wh
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 m
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 your
simultaneously keep
everything else working.
This is nontrivial BUT I'm working on it.
2009/4/6 Korey Sewell
> 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 l
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 on
The file I'm referring to is arch/alpha/tlb.cc and specifically the
translateAtomic() function implemented there.
Basically, having the "Read" mode is irrelevant there since it's given a
default type of "write" when it calls translateData(). Then in the
translateData() function it goes ahead and g
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 translateD
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 re
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 wrote:
> If I would like to add a new regression test
can I update the regression
stats?
Thanks 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 wrote:
> n/mJust took a little digging
>
> If a
nary) has changed; 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 wrote:
- 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
# HG changeset patch
# User Korey Sewell
# Date 1239339875 14400
# Node ID d4ff65e87a0bad86dd03c19fced4fdcd4ed68782
# Parent 0555121b5c5fb9fdfeb6f232421cf7a6c8d98b59
Edit AlphaISA to support the inorder model. Mostly alternate constructor
functions and also a few skeleton multithreaded support
# HG changeset patch
# User Korey Sewell
# Date 1239339925 14400
# Node ID 8542476836a75672fa06fe066e62b2b679319aea
# Parent d4ff65e87a0bad86dd03c19fced4fdcd4ed68782
Separate the TLB from the CPU and allow it to live in the TLBUnit resource.
Give CPU accessor functions for access and also bind
# HG changeset patch
# User Korey Sewell
# Date 1239340019 14400
# Node ID dc1c89c97e02450a3b5302286904ab1e763f4300
# Parent 8542476836a75672fa06fe066e62b2b679319aea
Expose memory access size and flags through instruction object
diff -r 8542476836a7 -r dc1c89c97e02 src/arch/alpha/isa/mem.isa
# HG changeset patch
# User Korey Sewell
# Date 1239342473 14400
# Node ID 64fcc70b469dc97e03fc1cd1a3bf7192e00e2b6f
# Parent dc1c89c97e02450a3b5302286904ab1e763f4300
Changes so that InOrder can work for a non-delay-slot ISA like Alpha.
Typically, changes have to do with handling misspeculated
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID cdb3bc0078182a8deaf592707b55aca1bf9559bf
# Parent 64fcc70b469dc97e03fc1cd1a3bf7192e00e2b6f
Remove subinstructions eaComp/memAcc since unused in CPU Models. Instead,
create eaComp that is visible from StaticInst object
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID 2ac6e5d7d8aa30b4f82417401f0c97f0339b505e
# Parent cdb3bc0078182a8deaf592707b55aca1bf9559bf
Fix indexing for misc. reg operands and update result-types for better tracing
of these types of values
diff -r cdb3bc007818 -r
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID 1ea36de4c34568f7a3561fb9b7ed7393b725692b
# Parent 2ac6e5d7d8aa30b4f82417401f0c97f0339b505e
Remove namespace from header file. Causes compiler issues that are hard to find
diff -r 2ac6e5d7d8aa -r 1ea36de4c345 src/cpu
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID ca55bb800d298db29634293b637e2e6a5eb31b3d
# Parent 1ea36de4c34568f7a3561fb9b7ed7393b725692b
Merge code to handle unified TLB.
diff -r 1ea36de4c345 -r ca55bb800d29 src/arch/alpha/regfile.hh
--- a/src/arch/alpha/regfile.hh
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID 98211627847247ccd203e243c38e579a2e443b2b
# Parent ca55bb800d298db29634293b637e2e6a5eb31b3d
allow InOrder and O3CPU to be compiled at the same time: need to make branch
prediction filed shared by both models
diff -r
# HG changeset patch
# User Korey Sewell
# Date 1239342519 14400
# Node ID d95ac474241eb0c7ce1ad1f71d57c60da547f946
# Parent 98211627847247ccd203e243c38e579a2e443b2b
create hello world regression for inorder-model
diff -r 982116278472 -r d95ac474241e tests/SConscript
--- a/tests/SConscript Fri
I'm assuming they''ll be some commentary , so I'll wait before I commit
this.
On Fri, Apr 10, 2009 at 1:54 AM, Korey Sewell wrote:
> - port alpha to inorder model
> - fix functionality to handle non-delay slot ISA
> - add hello regression test as a start
Hi Steve,
I agree it would great to get some organization there. I had been just
treating that as literally a "dump" for things that all CPU models need.
My theory to clean it up would be to add a "common" folder similar to how is
in the src/configs directory. Then in the common folder place a dir
nctions are for and why they're needed?
>
> Korey Sewell wrote:
> > # HG changeset patch
> > # User Korey Sewell
> > # Date 1239340019 14400
> > # Node ID dc1c89c97e02450a3b5302286904ab1e763f4300
> > # Parent 8542476836a75672fa06fe066e62b2b679319aea
> &g
What happened with the FloatRF is that other CPU models accessed the FloatRF
only through the main "RegFile" object but didnt instantiate the FloatRF
separately. Since the InOrder model wanted to instantiate the FloatRF
separately then it needs those accessor functions. Kind of odd that it wasnt
th
So will adding the "git = 1" then refreshing the patch queue do the trick or
do I need to start over with the patch and move files with the hg mv?
On Fri, Apr 10, 2009 at 1:58 PM, nathan binkert wrote:
> > In reading the hg docs, i thought when you did a "hg copy" it will copy
> the
> > history
> I didn't break anything that way, but it should really
> be translateTiming().
I noticed that the O3 model still uses translateAtomic() as well and meant
to ask the list should the O3 model (and InOrder) really be using the timing
version of the TLBs
Thoughts?
--
--
Korey L Sewel
Well,
I dont think pretending to do the access would work for the TLB necessarily.
I can see that the actual size of the access is irrelevant for the TLB
translation (right?). Maybe we can work around that.
But what about the type of access? That comes from the memory access flags
and the only ob
ou want to break it up more:
>
> 1. Instruction calls read with flags.
> 2. Build a request with the flags and the right size, and stick it in
> the dynInst.
> 3. Pull out the request, translate it, and stick it back in the dynInst.
> 4. Actually do the read with the translated r
.
>> 2. Build a request with the flags and the right size, translate it, and
>> stick it in the dynInst.
>> 3. Actually do the read with the translated request.
>>
>> Or if you want to break it up more:
>>
>> 1. Instruction calls read with flags.
>> 2. Buil
Comments below:
> There's still one aspect that confuses me though: why does translation
> need to be separated out of xc->read() and xc->write()? The model for
> all the other CPUs is that translation is part of that process. I can
> believe that in the InOrder model you may want to separate th
I'm pretty sure that was in the code a while back, but I can not locate this
currently in O3. Has this been removed?
In SE mode, I would think squashing after a system call is necessary because
real system calls would need to save/restore context to Memory before
returning to user-mode execution s
pointless at best,
> and misleading at worst (IMO).
>
> The difference with TLB overheads is that they're needed to more accurately
> model the execution time of the user code as well, so leaving them out is a
> more fundamental issue with respect to the things that SE mode i
t; O3 checks isSerializeBefore() and isSerializeAfter() but never checks
> isSerializing(), then an instruction marked IsSerializing will never
> actually serialize.
>
> Steve
>
>
>
> On Tue, Apr 14, 2009 at 11:17 AM, Korey Sewell wrote:
>
>> Thanks for the insight.
>
t,
> > and misleading at worst (IMO).
> >
> > The difference with TLB overheads is that they're needed to more
> accurately
> > model the execution time of the user code as well, so leaving them out is
> a
> > more fundamental issue with respect to the things that S
Collection of patches to allow MIPS to successfully run O3-Hello World App
again. Also, add regression to stabilize functionality.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
# HG changeset patch
# User Korey Sewell
# Date 1239850292 14400
# Node ID 7b685fee8773c2fe0bd09ec7abb0a43873aeed92
# Parent 0647c8b31a991cd2d20c48054cd6aba05878e332
Remove Shadowsets from Int & Arch. Reg Calculations
diff --git a/src/arch/mips/isa_traits.hh b/src/arch/mips/isa_traits.hh
-
# HG changeset patch
# User Korey Sewell
# Date 1239850525 14400
# Node ID ce539a58327b78b049f8af0bf8a00737f2b97640
# Parent 7b685fee8773c2fe0bd09ec7abb0a43873aeed92
Fix Branch Prediction for MIPS. Namely, i dont see the reason for updating the
branch history on anything that happens in decode
# HG changeset patch
# User Korey Sewell
# Date 1239850529 14400
# Node ID c55653331067e3493ff4da2665247017928ef43e
# Parent ce539a58327b78b049f8af0bf8a00737f2b97640
MIPS was using wrong serialization flag on syscall instructions allowing O3 to
handle SE mode syscalls incorrectly and speculate
# HG changeset patch
# User Korey Sewell
# Date 1239850532 14400
# Node ID dfe72826c0b7f146ef6c967506716a7c1ffef415
# Parent c55653331067e3493ff4da2665247017928ef43e
MIPS was never updated to use TLBS correcty in SE mode. The error was
forwarding translations directly to pageTable. The TLB
# HG changeset patch
# User Korey Sewell
# Date 1239850532 14400
# Node ID 8281a270a9a0cf52abbe38304cbd27b826f90450
# Parent dfe72826c0b7f146ef6c967506716a7c1ffef415
Add a Hello World Regression for MIPS O3
diff --git a/tests/quick/00.hello/ref/mips/linux/o3-timing/config.ini
b/tests/quick/00
on
ALPHA/SPARC to make sure I'm not breaking anything if I were to remove that
code.
Anybody have any thoughts on this (Gabe, Kevin?)?
On Wed, Apr 15, 2009 at 11:06 PM, Korey Sewell wrote:
> # HG changeset patch
> # User Korey Sewell
> # Date 1239850525 144
until execute (and
> you may want to wait until commit if that makes recovery substantially
> simpler).
>
> Steve
>
>
> On Wed, Apr 15, 2009 at 8:15 PM, Korey Sewell wrote:
>
>> This is the patch that will prevent me from committing.
>>
>> Basically, the
wer is to fix the real problem.
>
> Steve
>
>
> On Wed, Apr 15, 2009 at 9:16 PM, Korey Sewell wrote:
>
>> There is a bunch of DPRINTS in there that I kept in figuring out what's
>> going on.
>>
>> The actual fix is small in fetch_impl.hh:
>> &q
Eehhh
Well, yes and no.
I was thinking there has to be a better of way to implement optional
shadowsets (through parameters maybe?).
TotalArchRegs is used in the Mips Regfile so I kind of want to take
advantage of potentially working shadow set code and maybe move that in
there...
But i
> My question is why does the branch predictor matter as far as functional
> correctness?
>If it was wrong 100% of the time wouldn't that just make O3
> slow?
The problem isnt with branch prediction being wrong functionally, its
that there are assert statements that break execution from updating
th
Gabe, briefly can you talk about what you're big push is going to be on?
I'm really scrambling to get these MIPS fixes in for O3 since a major
culprit of it getting continually broken is the lack of a regression
test. People (including me) can change stuff and unknowingly break
MIPS code. Then, I
I'm wondering if anybody would find this useful or not.
Basically, when debugging, I often find myself going through
SConscript files trying to remember or find out what trace-flag is
available for a particular object.
For instance, just now, I wanted to view the Exec trace but didnt want
the sym
n unrealistic but not broken path instead,
> while the right answer is to fix the real problem.
>
> Steve
>
> On Wed, Apr 15, 2009 at 9:16 PM, Korey Sewell wrote:
>>
>> There is a bunch of DPRINTS in there that I kept in figuring out what's
>> going on.
>>
blurb too, so that you can see if you want is
> available.
> Lisa
>
> On Fri, Apr 17, 2009 at 2:56 AM, Korey Sewell wrote:
>>
>> I'm wondering if anybody would find this useful or not.
>>
>> Basically, when debugging, I often find myself going th
nt together into a composite flag and
> call it O3CPUAll.then not only would it be easy to see but easy to turn
> on.
> On Fri, Apr 17, 2009 at 11:47 AM, Korey Sewell wrote:
>>
>> Yea, that's helpful. I guess I am looking for a more fine-grained
>> control of thin
changeset 4d27997b548c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4d27997b548c
description:
mips-shadowsets: fix calcuations. \n Remove Shadowsets from Int &
Arch. Reg Calculations
diffstat:
2 files changed, 7 insertions(+), 4 deletions(-)
src/arch/mips/isa_trait
changeset f0841ee466a5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f0841ee466a5
description:
o3-delay-slot-bpred: fix decode stage handling of uncdtl. branches.\n
decode stage was not setting the predicted PC correctly or passing that
information back to fetch corre
changeset 0b0341bfb359 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0b0341bfb359
description:
mips-syscall: mark with correct flag. \nMIPS was using wrong
serialization flag on syscall instructions allowing O3 to handle SE mode
syscalls incorrectly and speculate on i
changeset 4c21637acedd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4c21637acedd
description:
mips-tlb-fix: check for alignment faults.\nMIPS was never updated to
use TLBS correcty in SE mode. The error was forwarding translations directly to
pageTable. The TLB shoul
changeset fd5ed84c460e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fd5ed84c460e
description:
o3-mips-regress: add hello word regression.
diffstat:
4 files changed, 890 insertions(+)
tests/quick/00.hello/ref/mips/linux/o3-timing/config.ini | 448 ++
tests
ow how to do the 2nd option correctly, so I dont
necessarily want to test run on the clean tree if thats the preferable
option.
I'm guessing the process would be:
- log into daystrom
- hg revert -r6035:6039
- Then repush my patches from my local tree
On Sat, Apr 18, 2009 at 10:45 AM, Korey S
Hey Nate,
yea, I would be looking for a variation of what your describing here.
Basically, I want to maybe do something like:
m5.debug configs/example/se.py --trace-all-objects -d --caches
So since this would be an O3 simulation, then that would mean I would
want all CPU flags, the TLB, the Cache
should be a one-line stand-alone summary. What you have here
>> would be OK if you just put a newline after the first period. I think Nate
>> is pushing us to use labels, something like "branch pred: fix for MIPS".
>>
>> Steve
>>
>> On Wed, Apr 15
The difference between 'All'...hI guess not much!
Other than you dont want 'Event' typically for the noise factor ...
Maybe I dont want the "Fault" flag on?
Like Lisa said, I was just trying to figure out if there was a way for
me to wrap up all context-specific, object information with a
> unconditional branches in made in decode consider delay slots, right?
>
> Gabe
>
> Korey Sewell wrote:
>> changeset f0841ee466a5 in /z/repo/m5
>> details: http://repo.m5sim.org/m5?cmd=changeset;node=f0841ee466a5
>> description:
>> o3-delay-slot-bpred
This definitely isnt a pressing issue, but is there any facility in
M5 so that I can give assert a message to go along with breaking
execution. I remember at Intel we had something
like this available in the simulator.
Panic, Fatal, etc. dont quite do the trick since you still typically
need to e
Steve's comment in a commit got me thinking about what we need to do
to get the SMT regressions in O3 back to respectability. If the SMT
can have some better tests, then that probably squashes a lot of
questions that we get on the list.
So, I want to take this up again soon, but have a few questio
In reference to src/arch/*/predecoder.hh:
I really think that somehow this predecoder code needs to be generalized
since if you look at the "predecoder.hh" for alpha,mips,arm, & sparc they
are 90% the same code. The difference for those ISAs is just the "moreBytes"
function which is still pretty m
f other places (lots in the CPUs) where there is
> duplicated code for the same reason. That would be at most a
> reorganization anyway, not a rewrite.
>
> Gabe
>
> Korey Sewell wrote:
> > In reference to src/arch/*/predecoder.hh:
> >
> > I really think that someho
201 - 300 of 720 matches
Mail list logo
