On Sun, Nov 15, 2009 at 4:27 PM, Gabe Black wrote:
> This sort of question should be on the m5sim-users mailing list. Please
> move it there.
>
> Agreed, but if he wants to actually dig into the code and fix it/submit a
patch should it go on m5-dev? its a little ambiguous what to do there...
-
Hey,
what CPU model are you using (assuming atomic-simple?)
Also, what's the changset revision # that you are referencing that broke
things?
I would like to look at it but I'm not exactly sure how to get to that
changeset # that you list (somebody know the hg command to extract it?).
On Fri,
OK thanks...I'll try to take a look at this soon, but if anyone has addtl
comments feel free!
On Fri, Dec 4, 2009 at 6:42 PM, Steve Reinhardt wrote:
> On Fri, Dec 4, 2009 at 3:39 PM, Korey Sewell wrote:
> > Also, what's the changset revision # that you are referencing th
Thanks for the check Gabe
I'll have some time next week to try to come up with a potential patch and
try to update the tree...
On Wed, Dec 9, 2009 at 6:39 PM, Gabriel Michael Black wrote:
> I looked briefly at that change earlier, and I do think it's likely
> that I broke it. I don't know h
>
> I haven't checked too carefully, but this same problem may be
> affecting ARM as well (since I think it uses the same paired
> floating-point register scheme). Also, other double-precision things
> like checking for NaNs may be broken by this change.
>
Yea, I know I have got a few of the regre
which inst in there is unsupported?... Does it not recognize the "move"???
On Sun, Dec 13, 2009 at 6:43 PM, Gabe Black wrote:
> I actually just ran into and straightened out (I think) the syscall
> interface issue. I basically added the missing calls and set
> set_thread_area to ignoreFunc. Now
> I think the unsupported instruction is the rdhwr instruction.
Aaah, i see more than likely that instructions is impl. specific so GDB
may not handle that correctly...
> I've got it
> working now, but it's hacked into m5-stable from several months ago,
> so it will take a bit of work to g
--git a/src/sim/process.hh b/src/sim/process.hh
> index ab9d64c..d663e92 100644
> --- a/src/sim/process.hh
> +++ b/src/sim/process.hh
> @@ -269,6 +269,9 @@ class LiveProcess : public Process
> uint64_t __pid;
> uint64_t __ppid;
>
> +// Thread pointer value (to su
;
> On Mon, Dec 14, 2009 at 2:37 PM, soumyaroop roy wrote:
> > The multiplier bug in inorder that was fixed a few months ago.
> >
> > -Soumyaroop
> >
> >
> > -- Forwarded message --
> > From: Korey Sewell
> > Date: Wed, Sep 16, 2009 at 10:02 AM
&
> This looks right to me and good catch. Does this look right to you,
> Korey? We should be able to get this in immediately by leaving off the
> change to the filterDoubles function for now.
>
Gabe,
Just saw you posted some MIPS patches...will review tomorrow...
--
- Korey
___
The first thing I would say is that implementing this could get interesting
but definitely is doable within the current framework.
#1 is that how do you detect a 64-bit FPU despite 32-bit INT registers. I
assume that some system register is set (cop0) so what you need to do on the
1st hand is in
> You shouldn't need to add any new operands to just change the width,
> you can use the type prefix. I think the way it's supposed to work is
> that all instructions in MIPS64 use the wide integer registers, and it's
> set up so it just works out for the 32 bit instructions. You -would-
> need to
All the patches look fine to me, except I'm wondering if that TP value
control register that you use isnt actually some a real register you can set
in the MIPS MT extension that has contains a bunch of control fields for
things of that nature... I would have to check that later but for now,
that's
> As far as I can tell from the MIPS documentation, only a MIPS64
> processor would have 64-bit wide FP registers.
However, these 64-bit
> specific instructions that only work on such a processor are part of
> the MIPS32 revision 2 ISA for some strange reason--they just have
> "unpredictable" affe
For the people interested in what's going on with the model, I've been
working with soumyaroop roy on some interesting development changes.
In particular, we are moving a lot of the hardcoded configurations and
putting them into Python scripts (e.g. pipeline configuration). The side
effect is that
Hi Matt/Steve,
sorry I'm late to the conversation.
In short, the reason it's implemented currently as a read-modify-write was
because what Matt found out to be true: the 3-byte store problem. At the
time of implementation, M5 was at the crossroads of another memory system
change (remember mergedme
get wierd if something
> tries to dereference a pointer to that type and do a direct
> assignment, something like:
>
> template
> bar(T *foo)
> {
> ...
> T *bar = (T *)baz;
> *bar = *foo;
> }
>
> But that might work too. I'm not sure.
>
> Gabe
I've posted documentation for the InOrderCPU model on the WIKI (thank
Soumyaroop for the help!). There should be enough there for anyone who wants
to get a general feel for what's going on before diving into the code. Check
it out here:
http://m5sim.org/wiki/index.php/InOrder
Also, there is a post
If memory serves me correctly, I dont think there is anything in the MIPS
spec that says how you have to implement the possible 3-byte operation for
swl/swr pairs, but just that it has to be functional.
For a more specific implementation about how a MIPS core might do this, I
bet one could browse
Great, thanks Matt!
I take a peek at the patch and can get this in the tree early next week if
no one else gets to it first.
On Wed, Jan 27, 2010 at 8:10 PM, Matt DeVuyst wrote:
> I found that checkpointing in M5 for the MIPS ISA was not working.
> There were two reasons for this: (1) During ch
changeset 0cf7d56ab5d7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0cf7d56ab5d7
description:
inorder: init internal debug cpu counters
- cpuEventNum
- resReqCount
diffstat:
4 files changed, 128 insertions(+), 58 deletions(-)
src/cpu/inorder/cpu.cc
changeset 6d7f25432d1c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6d7f25432d1c
description:
configs/inorder: add options for switch-on-miss to inorder cpu
diffstat:
3 files changed, 24 insertions(+), 2 deletions(-)
src/cpu/inorder/InOrderCPU.py |5 +
src/cpu
changeset 9b37243a6568 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9b37243a6568
description:
inorder: dont allow early loads
- loads were happening on same cycle as the address was generated which
is slightly
unrealistic. Instead, force address genera
changeset 02562dac0416 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=02562dac0416
description:
inorder: switch out buffer
add buffer for instructions to switch out to in a pipeline stage
can't squash the instruction and remove the pipeline so we kind of
changeset fe210e4ce76d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fe210e4ce76d
description:
inorder: add insts to cpu event
some events are going to need instruction data when they process, so
just
include the instruction in the event construction
d
changeset edf3d0c7a485 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=edf3d0c7a485
description:
inorder: squash on memory stall
add code to recognize memory stalls in resources and the pipeline as
well
as squash a thread if there is a stall and we are in
changeset d807273f17c0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d807273f17c0
description:
inorder: add event priority offset
allow for events to schedule themselves later if desired. this is
important
because of cases like where you need to activat
changeset 099ca6d9fc03 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=099ca6d9fc03
description:
inorder: activate thread on cache miss
-Support ability to activate next ready thread after a cache miss
through the activateNextReadyContext/Thread() function
changeset 444dc5183fb4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=444dc5183fb4
description:
inorder-cleanup: remove unused thread functions
diffstat:
4 files changed, 80 insertions(+), 332 deletions(-)
src/cpu/inorder/cpu.cc | 290 +++-
changeset ac9a5e69ba31 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ac9a5e69ba31
description:
inorder: ready/suspend status fns
update/add in the use of isThreadReady & isThreadSuspended
functions.Check in activateThread what list a thread is
on
changeset 4dacc68fb1f3 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4dacc68fb1f3
description:
inorder: fetch thread bug
dont check total # of threads but instead all
active threads
diffstat:
2 files changed, 9 insertions(+), 7 deletions(-)
src/cpu/ino
changeset c7e00670d83e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c7e00670d83e
description:
inorder: suspend in respool
give resources their own specific
activity to do for a "suspend" event
instead of defaulting to deactivating the thread for
changeset 4eb9b3a25a6c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4eb9b3a25a6c
description:
inorder: mem. mgmt. update
update address List and address Map to take
into account multiple threads
diffstat:
2 files changed, 13 insertions(+), 9 deletions
changeset 6e0d37136836 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6e0d37136836
description:
inorder: add threadmodel flag
this prints out messages relative to what
threading model is being used (smt, switch-on-miss, single, etc.)
diffstat:
1 file ch
changeset 17801e070302 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=17801e070302
description:
inorder: ready thread wakeup
allow a thread to wakeup and be activated after
it has been in suspended state and another
thread is switched out. Need to
changeset 0b8c6a579218 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0b8c6a579218
description:
inorder: add updatePC event to resPool
this will be used for when a thread comes back from a cache miss, it
needs to update the PCs
because the inst might of
changeset 8ae78a9733b0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8ae78a9733b0
description:
inorder: track last branch committed
when threads are switching in/out the CPU, we need to keep
track of special cases like branches. Add appropriate
v
changeset e350ae2a5018 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e350ae2a5018
description:
inorder: add/remove halt/deallocate context respectively
Halt is called from the exit() system call while
deallocate is unused. So to clear up things, just
changeset 862f3d824be7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=862f3d824be7
description:
inorder: set thread status'
set Active/Suspended/Halted status for threads. useful for system when
determining
if/when to exit simulation
diffstat:
2 files
changeset 7eb151d3881f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7eb151d3881f
description:
inorder: enforce stage bandwidth
each stage keeps track of insts_processed on a per_thread basis but we
should
be keeping that on a total basis inorder to enf
changeset 16d59c27bd01 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=16d59c27bd01
description:
inorder: pipeline stage stats
add idle/run/utilization stats for each pipeline stage
diffstat:
4 files changed, 55 insertions(+), 62 deletions(-)
src/cpu/inorder/cpu
changeset 96b33f6f9b7d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=96b33f6f9b7d
description:
inorder: ctxt switch stats
- m5 line enforcement on use_def.cc,hh
diffstat:
6 files changed, 194 insertions(+), 66 deletions(-)
src/cpu/inorder/cpu.cc
changeset c450ad6c82f4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c450ad6c82f4
description:
inorder-stats: add prereq to basic stat
only show requests processed when the resource is actually in use
diffstat:
2 files changed, 4 insertions(+), 2 deletions(-)
changeset df2a5f076618 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=df2a5f076618
description:
inorder: recvRetry bug fix
- on certain retry requests you can get an assertion failure
- fix by allowing the request to literally "Retry" itself
if
changeset f44ba2f42b5c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f44ba2f42b5c
description:
inorder: add execution unit stats
diffstat:
2 files changed, 22 insertions(+)
src/cpu/inorder/resources/execution_unit.cc | 17 +
src/cpu/inorder/resources/
changeset 6327f5071027 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6327f5071027
description:
inorder: user per-thread dummy insts/reqs
diffstat:
4 files changed, 30 insertions(+), 20 deletions(-)
src/cpu/inorder/cpu.cc | 35 +-
changeset 632ad41ac489 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=632ad41ac489
description:
inorder: object cleanup in destructors
diffstat:
10 files changed, 29 insertions(+), 7 deletions(-)
src/cpu/inorder/cpu.cc |5 +
src/cpu/inorder/
changeset 31ae0245e4ac in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=31ae0245e4ac
description:
inorder: add activity stats
diffstat:
6 files changed, 49 insertions(+), 12 deletions(-)
src/cpu/inorder/cpu.cc | 25 +
src/cpu/ino
changeset 88555fd4d220 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=88555fd4d220
description:
inorder: implement split loads
diffstat:
8 files changed, 373 insertions(+), 40 deletions(-)
src/cpu/inorder/inorder_dyn_inst.cc | 10 -
src/cpu/inorder/inorder_dyn_ins
changeset de51ab31b456 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=de51ab31b456
description:
inorder: implement split stores
diffstat:
4 files changed, 117 insertions(+), 31 deletions(-)
src/cpu/inorder/inorder_dyn_inst.cc |3
src/cpu/inorder/inorder_dyn_ins
changeset 7b99564233cd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7b99564233cd
description:
inorder: inst count mgmt
diffstat:
14 files changed, 210 insertions(+), 67 deletions(-)
src/cpu/inorder/SConscript |2
src/cpu/inorder/cpu.cc
changeset 2b656c4a5770 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2b656c4a5770
description:
inorder: double delete inst bug
Make sure that instructions are dereferenced/deleted twice by marking
they are
on the remove list
diffstat:
5 files changed,
changeset e307fe70f59d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e307fe70f59d
description:
inorder: update hello world alpha
diffstat:
3 files changed, 118 insertions(+), 103 deletions(-)
tests/quick/00.hello/ref/alpha/linux/inorder-timing/config.ini |6
tests
changeset 1670a39731f4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1670a39731f4
description:
inorder: twolf alpha regression
diffstat:
3 files changed, 148 insertions(+), 134 deletions(-)
tests/long/70.twolf/ref/alpha/tru64/inorder-timing/config.ini |4
tests/lo
changeset d96b8280b306 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d96b8280b306
description:
inorder: vortex alpha regression
diffstat:
3 files changed, 130 insertions(+), 116 deletions(-)
tests/long/50.vortex/ref/alpha/tru64/inorder-timing/config.ini |4
tests/
changeset a3a20caba701 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a3a20caba701
description:
inorder: update hello world mips
diffstat:
3 files changed, 120 insertions(+), 102 deletions(-)
tests/quick/00.hello/ref/mips/linux/inorder-timing/config.ini |1
tests/q
this one slipped through the cracks I meant to add a new priority here
instead of the offset (like discussed a while back)
I'll get to this and Matt's changes tomorrow...
On Sun, Jan 31, 2010 at 6:32 PM, Korey Sewell wrote:
> changeset d807273f17c0 in /z/repo/m5
&g
# HG changeset patch
# User Korey Sewell
# Date 1265078642 18000
# Node ID 42577d95f31471f661ce7337f290578f9d324374
# Parent a3a20caba7014ca897860c5ff6619cfa6bbaa43a
inorder/sim: add thread activation priority
diff --git a/src/cpu/inorder/cpu.cc b/src/cpu/inorder/cpu.cc
--- a/src/cpu/inorder
Looks like we might need a "Checkpointing - Internals" page on the wiki that
summarizes this.
I'm a little in the dark on what needs to be done myself... I assume the
main components for checkpointing would be serialize and unserialize, but I
guess traversing the function trace to/from those funct
> I don't really know anything about the situation here,
The problem is that threads activations/deactivation needs to happen after
the tick event. Typically, a CPU event will happen to do this and as long as
the CPU's Tick event has been scheduled before the activation/deactivation
event then we'
>
> 1. The first stage of the pipeline should not process the stage when a
> drainPending flag is set (or should this be associated specifically
> with the fetch logic?)
>
This sounds good. There is already a "checkSignals" type function in the
pipeline stage definition that you may be able to play
The checkSignalsAndUpdate() routine seems to be taking care of
> squashes for each thread. FirstStage::processStage() proceeds to fetch
> instructions after that. So, why not just insert the check on
> drainPending between the two tasks? Let me know if my understanding is
> incorrect.
>
Yea, I ju
>
> Yes, that is absolutely correct! the list of instructions to be
> removed during a tick by the cleanUpRemovedInsts() routine comprises
> of both instructions that graduate and instructions that get squashed!
> And, cleanUpRemovedInsts() just removes the instruction schedule
> associated (and it
>
> But fixing the two items above did not solve the problem. I figured
> (from the takeoverfrom() routines) that commit stage needs to reset
> its flags to that it does not go and squash the first instruction
> where the restoration is supposed to start from. Since I am not very
> familiar with th
Is there a way to get the run-time value of a stat?
Particularly, I have a vector stats that I am incrementing:
myStat[tid]++.
But, for debugging purposes, I would like to print out the stats value:
printf("Stat value is %i", myStat[tid])
but that will cause compiler errors with the Stat type.
I
:27 PM, Lisa Hsu wrote:
> Korey,
>
> Use myStat[tid].value()
>
> Lisa
>
>
> On Fri, Mar 5, 2010 at 9:07 AM, Korey Sewell wrote:
>
>> Is there a way to get the run-time value of a stat?
>>
>> Particularly, I have a vector stats that I am incrementi
The pass/fail groupings are probably a good idea.
Not sure why those inorder tests are failing, but I should be able to take a
look tomorrow. I haven't been paying too close of attention to the
changesets so I'm not sure off-hand what could be the culprit.
On Sun, Mar 7, 2010 at 8:27 PM, Gabe Bla
>
> The two failures this time are both print the error message "panic:
> Tried to read from invalid ipr N" where N is 296 for twolf and 307 for
> vortex.
>
I was able to pull all the new changesets and run the regressions
successfully just now so I'm a little perplexed to what's going on here.
Ma
> Because I want to model the branch penalty of an in-order core this
> will probably not affect the total number of inpredicted branches, nor
> the state of the branch predictor.
>
I'm a little confused here. Are you are saying that you want to know many
cycles do mispredicted branches contribute
changeset 7739d67ca64f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7739d67ca64f
description:
inorder: fix address list bug
diffstat:
3 files changed, 14 insertions(+), 13 deletions(-)
src/cpu/inorder/SConscript |2 +-
src/cpu/inorder/cpu.cc
changeset 5ae66d5f5ca2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5ae66d5f5ca2
description:
inorder: import name for addtl. bpred stats
diffstat:
3 files changed, 22 insertions(+), 19 deletions(-)
src/cpu/inorder/resources/bpred_unit.cc | 32 +++
changeset 0039707f915e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0039707f915e
description:
inorder: update vortex regression
diffstat:
3 files changed, 164 insertions(+), 145 deletions(-)
tests/long/50.vortex/ref/alpha/tru64/inorder-timing/config.ini |3
tests
changeset ba1ff0a71710 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ba1ff0a71710
description:
inorder: update twolf regression
diffstat:
3 files changed, 143 insertions(+), 125 deletions(-)
tests/long/70.twolf/ref/alpha/tru64/inorder-timing/config.ini |3
tests/l
changeset 6ecffa1e1ba2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6ecffa1e1ba2
description:
m5merge: ruby + inorder
automerge of updated inorder regressions and ruby style pass
diffstat:
6 files changed, 307 insertions(+), 270 deletions(-)
tests/long/50.vor
changeset 86558845c195 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=86558845c195
description:
inorder: update hello world for alpha and mips
diffstat:
6 files changed, 132 insertions(+), 118 deletions(-)
tests/quick/00.hello/ref/alpha/linux/inorder-timing/config.ini
changeset 8a05ebc9d372 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8a05ebc9d372
description:
m5merge(2): another merge of regression stats
diffstat:
92 files changed, 6869 insertions(+), 8071 deletions(-)
src/mem/ruby/buffers/MessageBuffer.cc
Steve,
where are you finding the 'Invalid IPR' message?
This bug is kind of elusive since everything is working fine on my local
machine, but trying to run off zizzer is painfully slow when I ssh in. I was
speculating that this might be a case of me different versions of gcc or
maybe something su
changeset 4524f8f80973 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4524f8f80973
description:
inorder: write-hints bug fix
make sure to only read 1 src reg. for write-hint and any other similar
'store' instruction. Reading the source reg when its not ne
changeset d4921c2e136b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d4921c2e136b
description:
inorder: update twolf/vortex regressions
diffstat:
4 files changed, 15 insertions(+), 17 deletions(-)
tests/long/50.vortex/ref/alpha/tru64/inorder-timing/simout|6 ++
changeset 6531ddc70176 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6531ddc70176
description:
m5: merge inorder updates
diffstat:
25 files changed, 1627 insertions(+), 1572 deletions(-)
src/arch/alpha/isa/mem.isa |6
src/arch/arm/isa/formats/m
I've been looking into this intermittently throughout the day (slow
zizzer!). I'm hesitant to just update the reference stats though since
again, the stats are different on my machine than on zizzer. But what
really makes me hesitant is that although the execution is correct, we're
seeing slightly
> haven't we been having problems with inorder-timing for a while?
>
I didnt notice that the test was failing for awhile since the tests only run
once-a-month on the weekend, and as Gabe noted, whether something fails or
not gets lost in the avalanche of messages there.
So yea, they've been hittin
istent, but
> > they're different?)
> >
> > If zizzer seems slow, do a 'top' and see what's running... unless
> > you're trying to use it while it's running a regression, it should be
> > very fast.
> >
> > Steve
> >
> >
t;
> + // NumInternalProcRegs=74 and IPR_DTB_CM=58, yet an error is flagged
>
> + //
>
> mode_type mode =
>
> (mode_type)DTB_CM_CM(tc->readMiscRegNoEffect(IPR_DTB_CM));
>
>
>
>
>
>
>
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-b
Following up on this, it seems that Brad is correct about where the
uninitialized values originate. Specifically, this code snippet in
src/arch/alpha/tlb.cc is the culprit:
> mode_type mode =
>
> (mode_type)DTB_CM_CM(tc->readMiscRegNoEffect(IPR_DTB_CM));
That uninitialized value even
ation in SE mode is, in my
> opinion, in the process initialization code. Conceptually it's sort of
> like the OS constructing the process context. The situation sounds
> similar to SPARC where 32 bit processes need to set a bit in a system
> register that forces translation to truncate
changeset c9b1a0ed2311 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c9b1a0ed2311
description:
inorder: timing for inst forwarding
when insts execute, they mark the time they finish to be used for
subsequent isnts
they may need forwarding of data. Howev
changeset 0f513e623826 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0f513e623826
description:
inorder: update regressions for fwd-ing patch
diffstat:
6 files changed, 30 insertions(+), 30 deletions(-)
tests/long/50.vortex/ref/alpha/tru64/inorder-timing/simout|
yea, I just saw that. what's the cause of that happening somewhat randomly?
Should we just re-run scratch all?
On Sun, Apr 11, 2010 at 11:16 AM, nathan binkert wrote:
> It seems that /dist was out of commission.
>
> Nate
>
> On Sun, Apr 11, 2010 at 4:26 AM, Cron Daemon
> wrote:
>> * bui
OK I agree with the premise of the patch, but not quite sure if the solution
is general enough yet.
Basically, you are saying if the instruction is executed (or resolved) then
we should call one branch predictor squash function BUT if we are just
making a prediction then we should call another squ
Hey all,
Is there a good way to access a DynInstPtr in GDB? For the most part
"inst->___" won't work, which forces more roundabout debugging then probably
has to be necessary.
If someone has a good way to get around this, I'll happily post it on the M5
wiki for them :)
--
- Korey
___
obvious "gotchas" I'm missing , let me
know.
On Fri, Apr 16, 2010 at 3:15 AM, Maximilien Breughe <
maximilien.breu...@elis.ugent.be> wrote:
> Try inst.data-> :-)
>
> Max
>
> On 04/16/2010 06:59 AM, Korey Sewell wrote:
>
> Hey all,
> Is there a good
eqNum' and 'p inst.data->readTid()'.
>
> regards,
> Soumyaroop
>
>
> On Fri, Apr 16, 2010 at 9:15 AM, Korey Sewell wrote:
>
>> Thanks for the response Max.
>>
>> Unfortunately, that's not working. Am I missing something? This is a
>> quic
On Fri, Apr 16, 2010 at 1:51 PM, Maximilien Breughe <
maximilien.breu...@elis.ugent.be> wrote:
> Yes, you are right, it's indeed not a general solution..
> We might be able to solve it by adding an extra variable to
> inorder_dyninst. Just a flag that let us check if the branch is allready
> resol
Hey all,
I've recently come across a couple of code segments that worry me a bit.
They are different spots in the memory system where you have a "curTick + 1"
to schedule something.
If you grep around, you'll see a # of these in the code:
src/cpu/inorder/cpu.cc:697:mainEventQueue.sched
> I'm also open to thoughts about how to handle this better in
> general... I agree that scheduling things on "curTick+1" just seems
> wrong, and it is confusing and a potential (and quite possibly
> current) source of timing model errors, so if there's a clean and easy
> way to improve it without
Excuse if this was previously answered, but is there a protocol we want to
use in terms of when to use reviewboard and when to just use patchbomb?
Or do we want to just literally replace using patchbomb w/ reviewboard?
-Korey
(BTW: Whomever thought of and set up the review board tool gets a +1!
Hello folks,
So I've got this decent-sized set of changesets (patches) for the InOrderCPU
that I want to commit to the tree.
The problem is that the changes are interspersed with some research patches
that I can't/don't want to commit.
So now instead of having to wade and nitpick through all thes
changeset 88cc2dc9472c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=88cc2dc9472c
description:
inorder: tick scheduling
use nextCycle to calculate ticks after addition
diffstat:
src/cpu/inorder/cpu.cc | 11 ++-
src/cpu/inorder/resource_pool
changeset e3311623d9f0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e3311623d9f0
description:
inorder: stall signal handling
remove stall only when necessary
add debugging printfs
diffstat:
src/cpu/inorder/pipeline_stage.cc | 22 +++-
1 - 100 of 720 matches
Mail list logo
