[m5-dev] startup issues

So we've got a bit of a muddle with initialization, and I'm looking for advice on how best to clean it up. RIght now we have the following phases for initializing SimObjects: 1. user script calls instantiate() a. call constructors b. connect ports c. call init() 2. user script optionally

[m5-dev] changeset in m5: cache: fix longstanding prefetcher bug

changeset 6b72468fbad3 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=6b72468fbad3 description: cache: fix longstanding prefetcher bug Thanks to Joe Gross for pointing this out (again?). Apologies to anyone who pointed it out earlier and we didn't

[m5-dev] changeset in m5: stats: update stats for SC protocol change

changeset c880d4812539 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c880d4812539 description: stats: update stats for SC protocol change Some subset of UpgradeReq messages shifted to the new SCUpgradeReq type. Other than that there are no signi

[m5-dev] changeset in m5: cache: fail store conditionals when upgrade los...

changeset f97b62be544f in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=f97b62be544f description: cache: fail store conditionals when upgrade loses race Requires new "SCUpgradeReq" message that marks upgrades for store conditionals, so downstream caches can

[m5-dev] changeset in m5: cache: fix dirty bit setting

changeset 8d92c2737ac8 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=8d92c2737ac8 description: cache: fix dirty bit setting Only set the dirty bit when we actually write to a block (not if we thought we might but didn't, as in a failed SC or CAS)

Re: [m5-dev] flyspray

I went through and closed the tasks that were obviously obsolete from my perspective. Nearly all of the rest look plausible to me, though many are outside my area of familiarity (e.g., the x86- and SPARC-specific ones). Perhaps the reality is that, as much as we'd like to prune this list, there i

Re: [m5-dev] flyspray

On Tue, Jun 15, 2010 at 4:32 PM, nathan binkert wrote: > I think what happened is that we just weren't disciplined (or > dedicated) enough to do it.  The problem is that usage is so bursty, > I'm not sure that a 1 month freeze would actually do much.  Perhaps we > should just update stable every 3

Re: [m5-dev] flyspray

On Tue, Jun 15, 2010 at 3:37 PM, Gabriel Michael Black wrote: > I'd vote to update it, although it is a chore and it does tend to get wildly > out of date. What were the reasons not to have it update automatically when > the full regressions passed? I think the issue there is that our current reg

Re: [m5-dev] flyspray

On Tue, Jun 15, 2010 at 4:15 PM, nathan binkert wrote: >> I agree that something needs to be done if we're going to make it >> useful.  We should have a default like "on this date we'll delete any >> bug that's not flagged to keep" (or whatever mechanism we want to use) >> just to start with a rel

Re: [m5-dev] flyspray

I agree that something needs to be done if we're going to make it useful. We should have a default like "on this date we'll delete any bug that's not flagged to keep" (or whatever mechanism we want to use) just to start with a relatively clean baseline. Steve On Tue, Jun 15, 2010 at 9:31 AM, nat

Re: [m5-dev] assertion bug in TimingSimpleCPU

On Sun, Jun 13, 2010 at 12:04 PM, Gabe Black wrote: > Gabe Black wrote: > > I just thought of another, more important drawback. In an in order > pipeline, the writeback will take up an extra pipeline stage, > effectively adding a bubble. In reality, I'd imagine the update would be > computed in th

Re: [m5-dev] changeset in m5: scons: make RUBY a regular (non-global) sticky var

problem with this commit is that now we don't build an > MI_example.  Does this break any existing regressions? > >  Nate > > On Mon, Jun 7, 2010 at 4:16 PM, Steve Reinhardt wrote: >> changeset 2302e04c506e in /z/repo/m5 >> details: http://repo.m5sim.org

[m5-dev] changeset in m5: scons: make RUBY a regular (non-global) sticky var

changeset 2302e04c506e in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=2302e04c506e description: scons: make RUBY a regular (non-global) sticky var and force it to True for builds that imply Ruby protocols (else unexpected things happen when testing these

Re: [m5-dev] RUBY as per-build vs. global option?

On Mon, Jun 7, 2010 at 8:24 AM, nathan binkert wrote: > Only that I'm eventually trying to get rid of the whole sticky_vars > thing and get to what is in effect global_sticky_vars. Isn't that fundamentally impossible, in that if you get rid of sticky_vars completely then there's no way to have di

Re: [m5-dev] RUBY as per-build vs. global option?

OK, I see that not having it as a global option causes the check in src/mem/ruby/SConsopts to fail, but I commented that out and things seem OK. Steve On Sun, Jun 6, 2010 at 8:55 PM, Steve Reinhardt wrote: > Is there any particular reason that RUBY is a global build option, and > not

[m5-dev] RUBY as per-build vs. global option?

Is there any particular reason that RUBY is a global build option, and not a per-build one? (That is, I can't build MIPS_SE w/o Ruby and then build ALPHA_SE or even ALPHA_SE_MOESI_hammer with Ruby in the same build directory.) Nate, you're the one that added RUBY to global_sticky_vars and not sti

[m5-dev] stats updates pushed

The commit notification email failed because I did the commit as user 'm5test', but it happened nonetheless: http://repo.m5sim.org/m5/rev/111f36470db4 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: ruby: get rid of RefCnt and Allocator stuff use base/refcnt.hh

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/21/#review37 --- Ship it! I haven't looked at this in great detail (and don't plan to), but

Re: [m5-dev] assertion bug in TimingSimpleCPU

ing the translation return > NoFault when the transaction is delayed, return ReplayFault or something > similar that would re-execute initateAcc(). This time the translation should > be cached and thus immediately available so it can return the proper fault or > NoFault. > > Any

Re: [m5-dev] changeset in m5: stats: fix stats diff script

All the O3 tests should fail tonight; I will update the stats tomorrow with the results of tonight's run. Steve On Sat, Jun 5, 2010 at 10:41 PM, Steve Reinhardt wrote: > changeset ba1a0193c050 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=ba1a0193c050 &g

[m5-dev] changeset in m5: stats: fix stats diff script

changeset ba1a0193c050 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=ba1a0193c050 description: stats: fix stats diff script Previously the return value ignored missing/added stats, making the regressions not tell you when you needed to update the

Re: [m5-dev] assertion bug in TimingSimpleCPU

erent enough now that it just adds to the confusion. I'm not advocating > that necessarily, but it sounds like it could help. > > Gabe > > Quoting Steve Reinhardt : > >> It could use some cleanup.  The idea has always been that it's the >> simplest CPU that c

Re: [m5-dev] assertion bug in TimingSimpleCPU

It could use some cleanup. The idea has always been that it's the simplest CPU that can drive the timing memory system, so there's no guarantee it will be simple in an absolute sense. But I'm sure it could be simpler if we worked at it. I think the combination of dealing with unaligned accesses

Re: [m5-dev] changeset in m5: Stats: fix dist stat and enable VectorDistStat

OK, Lisa and I figured out it's a combination of some renaming of the dist stats with some cluelessness in the diff script. Should be easy to take care of, and I'm on it. Steve On Sat, Jun 5, 2010 at 10:24 AM, Steve Reinhardt wrote: > I think this commit broke some things... star

Re: [m5-dev] changeset in m5: Stats: fix dist stat and enable VectorDistStat

I think this commit broke some things... starting in the 6/4 regressions, we get several errors like the one below from build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing. I don't know if it applies to all the o3 benchmarks but I expect it does. I also don't know if these are all the

[m5-dev] changeset in m5: More minor gdb-related cleanup.

changeset 3fc243687abb in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=3fc243687abb description: More minor gdb-related cleanup. Found several more stale includes and forward decls. diffstat: src/arch/alpha/ev5.cc| 2 -- src/arch/alpha/system.cc | 1 - sr

[m5-dev] changeset in m5: Minor remote GDB cleanup.

changeset dfd04ffc1773 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=dfd04ffc1773 description: Minor remote GDB cleanup. Expand the help text on the --remote-gdb-port option so people know you can use it to disable remote gdb without reading the

[m5-dev] changeset in m5: Act like enabling CPUs is no big deal,

changeset f056e1b65c13 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=f056e1b65c13 description: Act like enabling CPUs is no big deal, rather than a scary thing that might not work. diffstat: src/dev/alpha/backdoor.cc | 2 +- 1 files changed, 1 insertions(+),

Re: [m5-dev] ARM swig error

n binkert > wrote: >> It's not just ARM_SE is it?  that would be strange. >> >>   Nate >> >> On Thu, Jun 3, 2010 at 2:36 PM, Steve Reinhardt > wrote: >>> Done: >>> http://www.m5sim.org/flyspray/task/329 >>> >>> On Thu, J

Re: [m5-dev] ARM swig error

Done: http://www.m5sim.org/flyspray/task/329 On Thu, Jun 3, 2010 at 2:30 PM, nathan binkert wrote: > I can fix it, but it's not trivial.  Can you file a bug? > >  Nate > >> Just happened to notice this during a compile: >> >> swig -c++ -python -modern -templatereduce -Ibuild/gzstream >> -Ibuild/l

[m5-dev] ARM swig error

Just happened to notice this during a compile: swig -c++ -python -modern -templatereduce -Ibuild/gzstream -Ibuild/libelf -Iext -I/usr/include/python2.6 -Ibuild/ARM_SE -I/home/stever/hg/m5sim.org/encumbered -outdir build/ARM_SE/python/swig -o build/ARM_SE/python/swig/stats_wrap.cc build/ARM_SE/pyth

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

robably never look at the ARM code again, so if no one else cares then I won't stand in the way of getting this committed. Other than that and the minor thing below, I'm fine... thanks to both of you for making all the changes you did

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/20/#review30 --- src/arch/arm/insts/mem.cc

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

Give me a little bit... I'm looking it over now. Steve On Tue, Jun 1, 2010 at 6:49 AM, Ali Saidi wrote: > Anything else? I'm planning to commit this very soon. > > Thanks, > Ali > > On May 27, 2010, at 10:35 PM, Nathan Binkert wrote: > >> >> --

Re: [m5-dev] Connecting to cache ports

gt; Thank you, > Arka & Rathijit > Steve Reinhardt wrote: >> >> You need to use Port objects for this connection, just like the real >> CPUs do (and the memtester).  There isn't a lot of documentation on >> the wiki, but I think the details are discussed in the

Re: [m5-dev] Connecting to cache ports

You need to use Port objects for this connection, just like the real CPUs do (and the memtester). There isn't a lot of documentation on the wiki, but I think the details are discussed in the tutorial. Using the existing CPU or memtester code as an example is probably the best route. Let us know i

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > src/arch/arm/isa/formats/data.isa, line 41 > > <http://reviews.m5sim.org/r/20/diff/1/?file=206#file206line41> > > > > Is there a reason we can't use predefined bitfields here (and a ton of &g

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/20/#review25 --- src/arch/arm/isa/formats/data.isa

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/20/#review22 --- src/arch/arm/isa/formats/data.isa

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > src/arch/arm/insts/vfp.hh, line 314 > > <http://reviews.m5sim.org/r/20/diff/1/?file=190#file190line314> > > > > What's the purpose of these __asm__ statements? > > > > Gabe Black wrote:

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > src/arch/arm/insts/mem.hh, line 252 > > <http://reviews.m5sim.org/r/20/diff/1/?file=181#file181line252> > > > > seems like this should go in a .cc file > > Gabe Black wrote: > Wouldn't t

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

> On 2010-05-08 11:08:07, Steve Reinhardt wrote: > > Overall I'm kinda disappointed that most of the decode ended up in C++ and > > not in the ISA description language (I know the latter would have required > > some extensions)... now that it's in place and (pre

Re: [m5-dev] Review Request: ARM: Implement majority of instructions and some initial full-system support

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/20/#review15 --- Overall I'm kinda disappointed that most of the decode ended up in C++ and n

Re: [m5-dev] Review Request: summary

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/3/#review14 --- Can we delete this test review? - Steve On 2010-04-14 21:37:31, M5 Admin w

Re: [m5-dev] Review Request: eventq: Add a small cache to speed up insertions

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/7/#review13 --- src/sim/eventq.hh What happen

Re: [m5-dev] Review Request: params: add a mechanism to the config system to specify cycles

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/9/#review12 --- Ship it! I'm guessing this leads to confusing error messages when the object

Re: [m5-dev] Review Request: eventq: add classes for Clock, ClockTicker, and PeriodicEvent

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/8/#review11 --- How often do you use Clock without ClockTicker? It seems like ClockTicker d

Re: [m5-dev] Review Request: eventq: add a version of insert that takes a hint

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/6/#review10 --- How about giving this method a more meaningful name instead of just overloadi

Re: [m5-dev] Review Request: eventq: Add some statistics to the event queue.

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/5/#review9 --- Ship it! - Steve On 2010-04-18 22:33:48, Nathan Binkert wrote: > > ---

Re: [m5-dev] running memtest with x86 FS

On Tue, May 4, 2010 at 4:36 PM, nathan binkert wrote: >> Just to clarify: what script do you mean? > > There are (unfortunately) two.  One in the tests directory and one in > the configs/example directory. I think you want to use the configs/example script. As Nate says, it should just work; it'

Re: [m5-dev] integrating Bochs x86 cpu model into M5

I'm confused about why an isa_parser dependency breaks compilation. It seems like you could specify an ISA to build (might not even matter which one, but why not do X86_FS), and let M5 compile the existing models as is, but then add in the Bochs model too as something that's independent of the pars

Re: [m5-dev] curTick + 1 bugs in Memory System?

Hi Korey, Thanks for bringing this up. It is a confusing thing that we probably need to think through and find a solution for, and agree to and document what the expectations are on the Port interface as far as timing. I believe the assumption in the SimpleTimingPort case is that the device on t

Re: [m5-dev] Port Interface

Interesting idea... a few quick thoughts: - Seems like we're conflating two different types of requests here, things like block size which are just direct queries, and things like address range that are recursive. Is that a good idea? - How about having a non-abstract base implementation that's

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

Actually they are run weekly, not monthly, though if something goes wrong with a run you can miss a week or two. And yes, if it's not giving consistent results on your machine vs. zizzer then that's a problem. Is it consistent on each machine? (I.e., your machine is consistent, and zizzer is cons

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

Thanks for highlighting that. Looks like it's just a minor stats difference: = Statistics differences = Maximum error magnitude: +0.028348% Reference New Value Abs Diff Pct Chg Key statistics: host_inst_rate 49066 74587

Re: [m5-dev] SenderState

On Sat, Mar 27, 2010 at 12:20 AM, Gabe Black wrote: > What about one way packets that don't collapse back to the sender? Do we > have any of those? Or do we always collapse back at least with the ack? I'm not sure what you're referring to, Gabe... are you talking about atomic mode (that's what "c

Re: [m5-dev] SenderState

On Fri, Mar 26, 2010 at 10:32 PM, nathan binkert wrote: >> #1 sounds pretty good to me... 2 & 3 seem like overkill.  I don't >> think the overhead of the null pointer is that bad. > Ok, cool.  I'll cook up a diff. > >>> I'm partial to doing 1, 3, or nothing (in that order.)  With #1, we >>> could

Re: [m5-dev] SenderState

#1 sounds pretty good to me... 2 & 3 seem like overkill. I don't think the overhead of the null pointer is that bad. Steve On Fri, Mar 26, 2010 at 5:26 PM, nathan binkert wrote: > A common idiom with SenderState in the Packet object is the notion of > saving the previous sender state object and

Re: [m5-dev] changeset in m5: cpu: get rid of uncached access "events"

as to feed a pipeline > visualization tool like ASIM has.  We could just delete all of it. > >  Nate > > On Tue, Mar 23, 2010 at 8:54 AM, Steve Reinhardt > wrote: >> changeset d21d575a6f99 in /z/repo/m5 >> details: http://repo.m5sim.org/m5?cmd=changeset;node=d21d575a6f99 >&g

[m5-dev] changeset in m5: cpu: fix exec tracing memory corruption bug

changeset e21fe6a62b1c in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e21fe6a62b1c description: cpu: fix exec tracing memory corruption bug Accessing traceData (to call setAddress() and/or setData()) after initiating a timing translation was causing crash

[m5-dev] changeset in m5: cpu: get rid of uncached access "events"

changeset d21d575a6f99 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=d21d575a6f99 description: cpu: get rid of uncached access "events" These recordEvent() calls could cause crashes since they access the req pointer after it's potentially been de

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

plicate the bug so I can knock it out. > > Ideas? > > On Mon, Mar 22, 2010 at 2:54 PM, Steve Reinhardt wrote: >> >> We're still getting those 'invalid IPR' errors... >> >> On Sun, Mar 21, 2010 at 3:46 AM, Cron Daemon >> wrote: >> &

Re: [m5-dev] changeset in m5: ruby: improved isReadWrite fix me comment

More seriously, yes, something like: if (pkt->isReadWrite()) warn("this is probably broken"); does seem reasonable. On Mon, Mar 22, 2010 at 2:01 PM, Steve Reinhardt wrote: > Given that the code is unreachable, using warn() seems somewhat irrelevant. > :-) > > I can

Re: [m5-dev] changeset in m5: ruby: improved isReadWrite fix me comment

Given that the code is unreachable, using warn() seems somewhat irrelevant. :-) I can see your point though in terms of being able to grep for possible problems. Steve On Mon, Mar 22, 2010 at 1:57 PM, nathan binkert wrote: > IMHO, things like this shouldn't be comments, but should rather use >

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

We're still getting those 'invalid IPR' errors... On Sun, Mar 21, 2010 at 3:46 AM, Cron Daemon wrote: > * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/inorder-timing > FAILED! > * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/inorder-timing > FAILED! _

Re: [m5-dev] changeset in m5: ruby: Ruby support for LLSC

er gets executed. > > I'll check in a change now. > > Brad > > >> -Original Message- >> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On >> Behalf Of Steve Reinhardt >> Sent: Monday, March 22, 2010 9:13 AM >> To: M5 Developer

Re: [m5-dev] Cron /z/m5/regression/do-regression quick

There aren't any statistics differences... the lines like: = Statistics differences =* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. are just output getting mixed up because jobs are running concurrently, combined with cheesy grep-based summary generation. If t

Re: [m5-dev] changeset in m5: ruby: Ruby support for LLSC

t; -Original Message- >> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On >> Behalf Of Steve Reinhardt >> Sent: Sunday, March 21, 2010 11:05 PM >> To: M5 Developer List >> Subject: Re: [m5-dev] changeset in m5: ruby: Ruby support for

Re: [m5-dev] [PATCH] CPU: Make the CPU wait until initiateAcc finishes before calling completeAcc

Hi Gabe, On Sun, Mar 21, 2010 at 5:22 PM, Gabe Black wrote: > It's been a while since I've looked at this, but I want to make sure I > remember to respond so I don't want to wait until I have a chance to > re-research all this. Isn't the problem that initiateAcc ends up calling > completeAcc mid-

Re: [m5-dev] [PATCH] CPU: Make the CPU wait until initiateAcc finishes before calling completeAcc

Thanks to Brad's prompting, I took another look at this tonight. I think the fundamental problem is that the transition to split-transaction translation didn't move all the operations that depend on the translation completing into the translation callback or something that was guaranteed to run af

Re: [m5-dev] changeset in m5: ruby: Ruby support for LLSC

Comments below... On Sun, Mar 21, 2010 at 10:47 PM, Brad Beckmann wrote: > changeset 185ad61a4117 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=185ad61a4117 > description: >        ruby: Ruby support for LLSC > > diffstat: > > 4 files changed, 102 insertions(+), 20 deletion

Re: [m5-dev] changeset in m5: TimingSimpleCPU: Fixed uncacacheable request re...

I should have noticed this the first time around... this fix doesn't work in the sense that whether or not a request is uncacheable is typically determined during translation (i.e., cacheability is often an attribute of the PTE), so even though moving this test up above the translation avoids the l

Re: [m5-dev] [PATCH 07 of 31] m5: Fixed request read bug flagged by Valgrind

gt; (/tmp/bbeckman/m5/build/ALPHA_SE_MOESI_hammer/cpu/simple/timing.cc:832) > ==27646==    by 0x42F8AB: Port::sendTiming(Packet*) > (/tmp/bbeckman/m5/build/ALPHA_SE_MOESI_hammer/mem/port.hh:186) > ==27646==    by 0x576756: Bus::recvTiming(Packet*) > (/tmp/bbeckman/m5/build/ALPHA_SE_MOESI_ha

Re: [m5-dev] [PATCH 07 of 31] m5: Fixed request read bug flagged by Valgrind

ver it is even more confusing because it deals with two >> different pointers to traceData.  I have a patch that has a heavyweight fix >> for that bug, but I didn't send it out for review because I couldn't figure >> out how to get it to compile with the O3 cpu model.  If yo

Re: [m5-dev] [PATCH 07 of 31] m5: Fixed request read bug flagged by Valgrind

't figure > out how to get it to compile with the O3 cpu model.  If you're interested, I > can send that out as well. > > Brad > > > -Original Message- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of > Steve Reinhardt >

Re: [m5-dev] [PATCH 00 of 31] Ruby updates and simple perf. optimizations

On Thu, Mar 18, 2010 at 7:00 PM, Beckmann, Brad wrote: > I appreciate all the feedback on my patches, but I never got a response to my > M5 dynamic data question.  If you have the time, I would like to understand > under what criteria do M5 cpus and devices use static vs. dynamic data? Sorry ab

Re: [m5-dev] [PATCH 24 of 31] m5: Added public method to determine if the packet includes data

On Thu, Mar 18, 2010 at 5:33 PM, nathan binkert wrote: >>> And just as an aside, we really need to get rid of these functions >>> that just test a flag and make it easy to test the flags directly. >> >> I'm not so sure I agree... these accessors hide the fact that we're >> packing all these flags

Re: [m5-dev] [PATCH 17 of 31] ruby: Ruby support for sparse memory including direct support in the

On Thu, Mar 18, 2010 at 4:36 PM, nathan binkert wrote: > - You have some more random whitespace changes in there. > - You seem to have made some changes to code that was commented out. > Can we just remove that code? > - Is SparseMemory a Ruby specific thing, or could it be moved to src/mem? > - P

Re: [m5-dev] [PATCH 31 of 31] ruby: Added Null data support to the DMASequencer

Being more explicit can be a bad thing, when repetition and unnecessary fluff obscure the really important things. That's why we have pronouns, for example. Of course it's subjective exactly where the line is. For the record, I'm more tolerant than Nate of pointer comparisons to NULL, even thoug

Re: [m5-dev] [PATCH 24 of 31] m5: Added public method to determine if the packet includes data

On Thu, Mar 18, 2010 at 4:41 PM, nathan binkert wrote: > And just as an aside, we really need to get rid of these functions > that just test a flag and make it easy to test the flags directly. I'm not so sure I agree... these accessors hide the fact that we're packing all these flags into a singl

Re: [m5-dev] [PATCH 23 of 31] ruby: reordered vnets for MI_example to match PerfectSwitch priority

Seems like this series of patches that just shuffles priorities could (should?) be folded together. Steve On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > # HG changeset patch > # User Brad Beckmann > # Date 1268941833 25200 > # Node ID 7b9079a51a5292285396cf2c43015d89f8c27cc0 > # Parent

Re: [m5-dev] [PATCH 15 of 31] ruby: Ruby support for LLSC

On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > diff --git a/src/mem/ruby/system/RubyPort.cc b/src/mem/ruby/system/RubyPort.cc > --- a/src/mem/ruby/system/RubyPort.cc > +++ b/src/mem/ruby/system/RubyPort.cc > @@ -210,20 +210,31 @@ >         pc = pkt->req->getPC(); >     } > > -    if (pkt-

Re: [m5-dev] [PATCH 10 of 31] ruby: removed RubyMemory.py from src/mem

This should definitely be combined with the the changeset that removes rubymem.cc. I'd go one step further and just fold all the changesets that remove unused files together, but that's optional IMO. Steve On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > # HG changeset patch > # User Bra

Re: [m5-dev] [PATCH 07 of 31] m5: Fixed request read bug flagged by Valgrind

It seems very odd that translateTiming would delete the request object... can you point out where that happens? I couldn't find it in the alpha or x86 tlb code. Thanks, Steve On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > # HG changeset patch > # User Brad Beckmann > # Date 126894182

Re: [m5-dev] [PATCH 06 of 31] ruby: Python config files now sets a unique id for each sequencer

This patch is OK, but it reminds me that it would be nice to rename the "version" field to something like "id". It took me a while to figure out that's what "version" really means in Ruby. On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > # HG changeset patch > # User Brad Beckmann > # Da

Re: [m5-dev] [PATCH 03 of 31] ruby: Fix MOESI_hammer cache profiler calls for L2 misses

Hi Brad, Does SLICC have a logical negation operator? You know my opinion about boolean tests coded as explicit comparisons with true and false :-). Steve On Thu, Mar 18, 2010 at 3:46 PM, Brad Beckmann wrote: > # HG changeset patch > # User Brad Beckmann > # Date 1268935351 25200 > # Node ID

Re: [m5-dev] [Parallelizing m5] memory questions

On Mon, Mar 8, 2010 at 7:34 PM, Ali Saidi wrote: >> Aborting atomicAccess completely when a writeback deadlocks results in >> functional errors in the program so I have to do it like this, which >> is more >> efficient anyway. Can anyone foresee any simulation errors resulting >> from >> interrupt

Re: [m5-dev] tests

In general this sounds good... it seems like one issue that we're touching on is that for many current tests we have a sparse matrix of applicability: there are ISAs, configs (with and w/o ruby), OSes, etc. It would be nice to specify a related set of tests concisely but it's actually complex to pr

Re: [m5-dev] tests

On Sun, Mar 7, 2010 at 11:50 PM, Gabe Black wrote: > >> (Practically speaking, do we >> support anything other than linux on any other ISA?) >> > > Only supporting Linux doesn't mean the OS never changes. It would be > nice to be able to test both 32 and 64 bits of Linux in both FS and SE, > or ev

Re: [m5-dev] tests

This looks like a good start... I agree with you and Brad both that explicitly enumerating the tests and making sure we can add tests via EXTRAS are key features. My inclination is to push it a little farther in terms of abstraction though... all we really need for a test is a command to run and a

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

Yea, I'd been thinking too that it would be nice to have an easier way of seeing if any tests failed. 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. Thanks for the reminder about your test email, N

Re: [m5-dev] changeset in m5: Config: Fix fs.py's call to CacheConfig.config_...

I sympathize... I've long thought that (1) our configuration scripts are a big mess, and should be redone to be modular components that people can reuse rather than "examples" that people just hack on willy-nilly to make them do what they want and (2) that the regressions should rely more on the co

Re: [m5-dev] [Parallelizing m5] memory questions

On Fri, Feb 26, 2010 at 12:44 PM, Stijn Souffriau wrote: > > To be fair, when I said disproves your hypothesis, I should have said that > the assumption that synchronizing every couple of cycles would work fast is > wrong and that high accuracy can still be obtained with much less > synchronizatio

Re: [m5-dev] [PATCH 00 of 12] Changes to isa_parser

These all look pretty good to me. Nice to get rid of cpu_models.py... that was one of those things that looked pretty cool when you compare it to 'make', but quickly started to look ugly once we really got into scons. Steve On Fri, Feb 26, 2010 at 6:31 PM, Nathan Binkert wrote: > This set of pa

Re: [m5-dev] [Parallelizing m5] memory questions

On Fri, Feb 26, 2010 at 11:15 AM, Stijn Souffriau wrote: >> Our assumption when we've talked about this has been that we'd just do >> a conservative simulation with relatively frequent synchronization >> (based on the limited lookahead you can get on a bus), and hypothesize >> that on a CMP the sy

Re: [m5-dev] [Parallelizing m5] memory questions

On Fri, Feb 26, 2010 at 6:06 AM, wrote: > Quoting Steve Reinhardt : > >> For timing mode, our vision has always been that the interaction >> between threads would happen inside of certain specially written >> SimObjects and not at the port interface.  As it looks li

Re: [m5-dev] [Parallelizing m5] memory questions

Hi Sitjn, Glad to hear you're making progress. It's always the case that once you really get into something you run into issues that you hadn't anticipated, so I'm glad you're out there blazing the trail. I hadn't really given atomic mode any thought as far as parallelization, so I'm glad you br

Re: [m5-dev] Cron /z/m5/regression/do-regression --scratch all

There's a more general problem here, which is that the 2/14 regression finished one minute after the 2/21 regression, 33 hours after the 2/21 regression started (and 9 hours after the 2/22 regression). I don't think scons likes having multiple builds going on simultaneously, so there may be some c

Re: [m5-dev] Implementing checkpointing for inorder

On Sat, Feb 6, 2010 at 9:08 AM, soumyaroop roy wrote: > Let me rephrase my last question: > Is there any way that a comparison could be performed between the > checkpoint output by inorder with that output by a simple CPU? Say, if > the number of committed instructions in both are the same when th

Re: [m5-dev] Cron /z/m5/regression/do-regression--scratch all

; > Brad > > > -Original Message- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of > Steve Reinhardt > Sent: Monday, February 01, 2010 8:55 AM > To: M5 Developer List > Subject: Re: [m5-dev] Cron > /z/m5/regression/do-regression--scratch

<    2   3   4   5   6   7   8   9   10   11   >