On Wed, Oct 14, 2009 at 5:10 PM, nathan binkert wrote:
>> + reschedule(tickEvent, curTick + tickEvent.when());
>
> This seems pretty suspect to me. Generally, when we unserialize
> events, we first serialize the event time and then schedule it later.
> In fact, the way that the existing event
Note that running 'util/regress --variants=debug,opt,fast' should
capture all these (except POWERPC_SE) in a much shorter command line.
Once POWERPC_SE is ready to go it should be added to that script too.
Steve
On Thu, Oct 15, 2009 at 4:01 PM, nathan binkert wrote:
> I'm trying to compile absol
I'm sure Tim knows best wherher he's implemented POWER or PowerPC...
If it is the latter, I'd favor using PPC for naming just to keep
things brief.
Steve
On 10/16/09, nathan binkert wrote:
> currently the new PowerPC port is in the src/arch/powerpc directory
> and the isa is called PowerpcISA.
Setting NO_FAULT in the mem flags should be all you need to do for a
prefetch. This is how software prefetch instructions work on Alpha (or at
least worked at some point in the past). If something in a CPU model is not
handling NO_FAULT properly, then I'd say that's your bug.
Steve
On Fri, Oct
Hi Tim,
That assertion is just letting you know that it doesn't make sense to
translate a request that crosses a page boundary. I'm guessing that in our
other RISC ISAs we check alignment first, so you get an alignment fault
before you even try to translate the access. The alignment fault will t
The NO_FAULT behavior in Alpha is still the correct behavior model in my
opinion (and corresponds to what Ali described). I had not realized that
the implementation was Alpha-specific though; thanks for tracking that down,
Gabe.
I'm also amazed that the PREFETCH flag is not used anywhere... that'
On Mon, Oct 19, 2009 at 12:46 PM, nathan binkert wrote:
>
> > StaticInst::decode() Perhaps replication would be a good place to start.
> I
> > think the structure is just accessed too much to have any kind of
> locking.
> I agree that replication can work, but I'd say we start with a rwlock
> and
gt;
> Ali
>
>
> On Mon, 19 Oct 2009 13:05:21 -0700, Steve Reinhardt
> wrote:
> > On Mon, Oct 19, 2009 at 12:46 PM, nathan binkert
> wrote:
> >
> >>
> >> > StaticInst::decode() Perhaps replication would be a good place to
> >> > start.
Brad's issues with the timer device and checkpointing reminded me that I
wasn't really happy with that code; in particular, the redundant storage in
both clock_data[] and curTime seemed bound to cause problems when they got
out of sync, and in fact Brad's checkpointing fix was incomplete in that it
best place to do this? In LSQUnit::insertStore would be
> the
> >
> > easiest place, but is that the correct place for it? However, since this
>
> > is Power specific, maybe it should be handled within the code for this
> ISA
> >
> > only? Any thoughts on thi
ugh I can understand if that wasn't perfectly obvious from
reading the code :-).
Steve
>
> Tim
>
> On Wed, 21 Oct 2009 16:35:32 +0100, Steve Reinhardt
> wrote:
>
> > Actually no... x86 handles this by hacking up the CPU model to
> > dynamically
> > generate t
You'll need to add reference outputs under tests/{quick,long} as well.
Steve
On Wed, Oct 28, 2009 at 9:53 AM, Ali Saidi wrote:
>
> The regressions on zizzer execute util/regress in the cloned repository so
> I believe so.
>
> Ali
>
> On Wed, 28 Oct 2009 09:55:26 -0700, nathan binkert
> wrote:
On Wed, Oct 28, 2009 at 10:08 AM, nathan binkert wrote:
> > You'll need to add reference outputs under tests/{quick,long} as well.
> Yeah, we already have a 00.hello test in there. I was most concerned
> about making sure that it got compiled.
>
> OK, I did look for it but somehow missed it the
changeset 9c3577d9704a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9c3577d9704a
description:
stats: update memtest-ruby
I don't know if the new stats are right or not, but we've
been too long with a useless regression so I'm just going
to updat
changeset c79d72abdbe5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c79d72abdbe5
description:
o3: get rid of unused physmem pointer
diffstat:
3 files changed, 7 deletions(-)
src/cpu/o3/cpu.cc|1 -
src/cpu/o3/cpu.hh|3 ---
src/cpu/o3/thre
changeset 4b6fb0a99039 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4b6fb0a99039
description:
slicc: whack some of Nate's leftover debug code
diffstat:
1 file changed, 3 deletions(-)
src/mem/protocol/SConscript |3 ---
diffs (13 lines):
diff -r b95abe00dd9d -r 4
changeset 028047200ff7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=028047200ff7
description:
slicc: tweak file enumeration for scons
Right now .cc and .hh files are handled separately, but then
they're just munged together at the end by scons, so it
changeset c77e698abe9c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c77e698abe9c
description:
scons: deal with generated .py files properly
diffstat:
1 file changed, 7 insertions(+), 7 deletions(-)
src/SConscript | 14 +++---
diffs (44 lines):
diff -r a532
On the face of it, it doesn't sound that bad, but how often does this
really occur? If you have a SimObject that regularly has multiple
events scheduled at the same tick & priority, and is smart enough to
keep track of when that happens, why not have that SimObject chain its
own events itself (i.e
On Wed, Nov 11, 2009 at 9:22 PM, nathan binkert wrote:
>> On the face of it, it doesn't sound that bad, but how often does this
>> really occur? If you have a SimObject that regularly has multiple
>> events scheduled at the same tick & priority, and is smart enough to
>> keep track of when that h
OK, I had completely forgotten about your binning thing... just went
back and looked at the code to refresh my memory. I thought you were
trying to add something like binning in with this extension you're
proposing, but it's already there. So what you're saying is that
there'd be a second overloa
On Wed, Nov 11, 2009 at 10:24 PM, nathan binkert wrote:
> Oh, there's one more thing. Currently, an event technically doesn't
> have access to the event queue that it was scheduled on. (It is in
> there if you #define DEBUG though). This makes the idea of a periodic
> event a little clumsy sinc
On Wed, Nov 11, 2009 at 11:01 PM, nathan binkert wrote:
>> Yea, that's exactly the solution I was thinking of when I read the
>> first paragraph. It is a lot of code to change, but you could do it
>> all with one big regex replacement, so I don't think it's that big of
>> a hurdle.
> My gut prefe
EIO uses a flex-generated lexer to parse the trace file, and it
wouldn't surprise me at all if that's not thread-safe. Perhaps newer
versions of flex enable thread-safe lexing.
Steve
On Thu, Nov 12, 2009 at 4:09 AM, Stijn Souffriau
wrote:
> Hi again,
>
> I'm currently testing my code with eio t
On Wed, Nov 18, 2009 at 8:39 PM, nathan binkert wrote:
>> ruby: cache configuration fix to use bytes
>> Changed cache size to be in bytes instead of kb so that testers can
>> use very
>> small caches and increase the chance of writeback races.
>
>
>> num_cores = 2
>> -l1_cac
M5 has multiple CPU models, and the memory system can run in either a
timing or functional ("atomic") mode. The memory system only supports
one mode at a time, but you can mix simple and complex CPU models
simultaneously in a single system.
Steve
On Tue, Nov 17, 2009 at 9:37 AM, wrote:
>
> Doe
Hi Tim,
Sorry for the delay in getting back to you... it's been a busy few
weeks. I had to go back and look at your earlier patches to make
sense of this one. I'll send some comments on those separately.
I'd say the main thing that could be cleaned up here is that you want
to extend the "ExecCo
This looks pretty straightforward to me...
On Mon, Nov 9, 2009 at 5:30 AM, Timothy M. Jones wrote:
> # HG changeset patch
> # User Timothy M. Jones
> # Date 1257772283 0
> # Node ID 861198113ecaf172b6d1e874cda4d13c92bdb38a
> # Parent e9f450b4b4f276dd3ed69dd63a540dda2796de60
> Power ISA: Add an
Looking at just the part I've left below, it looks like you're
separating out the split vs non-split calls at the top, and then they
combine back into common functions at the bottom... I think it would
be cleaner if we got rid of the separate calls, and just used NULL
values for the split packets a
Hi Tim,
It looks like you lost the initialization of isUncacheable... is that safe?
> diff --git a/src/cpu/base_dyn_inst.hh b/src/cpu/base_dyn_inst.hh
> --- a/src/cpu/base_dyn_inst.hh
> +++ b/src/cpu/base_dyn_inst.hh
> @@ -861,29 +871,14 @@
> Request *req = new Request(asid, addr, sizeof(T),
On Wed, Dec 2, 2009 at 2:01 AM, Timothy M Jones wrote:
> Well, the problem is when you get speculative memory accesses. Even in
> the ISAs that don't need split loads and stores, an address on a
> speculative path can generated that requires splitting. Of course, these
> instructions are later s
Your logic looks fine to me... I think Kevin would have to speak up to
say if there's any intended behavior here or if this is truly a bug.
Steve
On Tue, Dec 1, 2009 at 7:33 AM, Timothy M Jones wrote:
> Hi everyone,
>
> I've noticed a slight problem in using the branch predictor that's causing
>
I do have comments, just haven't had time to think them through and
type them out yet. It's on my to-do list for this afternoon.
Steve
On Fri, Dec 4, 2009 at 10:29 AM, Gabe Black wrote:
> Does anybody have any comments? I'd like to address any issues sooner
> rather than later.
>
> Gabe
>
> Gab
On Fri, Dec 4, 2009 at 3:39 PM, Korey Sewell wrote:
> Also, what's the changset revision # that you are referencing that broke
> things?
That hex code he sent is the changeset revision number, you can use it
directly as an argument to "-r". The little decimal numbers aren't
portable across diffe
Some of these are really mine rather than Brad's, so don't be in too
much of a hurry to blame him if you see something you don't like.
We'll fix up the attributions before we push. I've got to get used to
using "qnew -U" now that we're using a shared patch queue.
Glad to see you got these out, Br
On Sat, Dec 12, 2009 at 7:49 PM, nathan binkert wrote:
>> Some of these are really mine rather than Brad's, so don't be in too
>> much of a hurry to blame him if you see something you don't like.
>> We'll fix up the attributions before we push. I've got to get used to
>> using "qnew -U" now that
On Sun, Dec 13, 2009 at 8:57 PM, Vince Weaver wrote:
> I did finish running and verifying spec2k on x86_64 (it took longer than
> it should have due to an unfortunate power-outage on our cluster). The
> benchmarks all finished, and the retired instruction count matches actual
> hardware perf coun
On Wed, Dec 16, 2009 at 4:33 PM, Gabriel Michael Black
wrote:
> Quoting Vince Weaver :
>
>> On Wed, 16 Dec 2009, Steve Reinhardt wrote:
>>
>>> On Sun, Dec 13, 2009 at 8:57 PM, Vince Weaver wrote:
>>> > I did finish running and verifying spec2k on x86_64 (i
On Thu, Dec 17, 2009 at 1:59 PM, Gabriel Michael Black
wrote:
>
> Yeah, picking the microops was a big concern for me when I was
> starting out. If you remember, I closely based what we have now on
> that patent I found for what looks like an older, 32 bit version of
> AMD's integer microop set. T
On Mon, Dec 21, 2009 at 9:03 AM, nathan binkert wrote:
> Overall, things look pretty good. There are more or less four things
> that you've done that need work.
>
> 1) You created SimObjects for all of the ruby objects and in the
> process, you didn't give any help strings to any of the parameter
On Mon, Dec 21, 2009 at 12:35 PM, nathan binkert wrote:
>> diff -r 8f73bf7c3c5e -r 5d3a90f0ef4c src/mem/slicc/parser.py
>> --- a/src/mem/slicc/parser.py Sat Dec 12 14:37:14 2009 -0800
>> +++ b/src/mem/slicc/parser.py Sat Dec 12 14:37:14 2009 -0800
>> @@ -418,6 +416,10 @@
>> "param : ty
On Mon, Jan 4, 2010 at 2:26 PM, nathan binkert wrote:
>> I don't follow... are you complaining about the syntax we're
>> introducing, or the way we're parsing it? In this particular case,
>> the syntax seems straightforward to me, as we're just extending the
>> state-machine parameter block to al
On Mon, Jan 4, 2010 at 2:37 PM, nathan binkert wrote:
>> So you were thinking it should be 'int buffer_size(10)'?
> No. This is what I was getting at about organic growth. I think = is
> the natural choice given what is there, but if we were to try to start
> with a fresh language that tried to
I spent the day working over the patches, so even though it might be
another few days until we send out updated versions, I wanted to
mention how I've addressed these issues:
On Mon, Dec 21, 2009 at 10:19 AM, Steve Reinhardt wrote:
> On Mon, Dec 21, 2009 at 9:03 AM, nathan binker
On Mon, Jan 4, 2010 at 12:25 PM, nathan binkert wrote:
>> To answer your question about the ruby tester. While both the ruby tester
>> and memtester use false sharing to test coherence, they behave in different
>> ways. To my understanding, the Memtester has all cpus write a cache block
>> be
On Tue, Jan 5, 2010 at 6:33 AM, nathan binkert wrote:
>> I started to do this, but the original includes were not sorted, so it
>> causes cascading problems through the whole patch set when you sort
>> everything the first time you add an include. I can see where that
>> could complicate integrat
Yes and no... it basically works, but it's undergoing a lot of work
for better integration. If at all possible, I'd say hold off a month
or so and it'll be in much better shape.
Steve
On Mon, Dec 21, 2009 at 4:59 PM, wrote:
>
> Does m5 integrate ruby now? Can I simulate on chip network of ruby
Thanks for getting these patches out, Brad.
On Thu, Jan 14, 2010 at 10:19 PM, Brad Beckmann wrote:
> - These patches do not remove the old ruby config and rubymem files.
> However, once these patches are checked in, those old files won't be needed.
> Anyone have an opinion on how long they w
My guess is that the instruction definition should be rewritten to do
a store of the correct number of bytes and not a read-modify-write. I
don't think there's a reason the store function shouldn't handle a
3-byte store; somebody correct me if I'm wrong.
Steve
On Tue, Jan 19, 2010 at 2:38 PM, Ma
tions that would require RMW
though (particularly since MIPS uses LL/SC for atomic ops, which is
the main reason you'd want RMW).
Have we discussed doing 3-byte memory ops on the list before? It's
clear it would require some new functionality at the read()/write()
ExecContext interface, but
e though as Matt found out.
>>>
>>> I believe the only addition that we previously made was to add a "unaligned"
>>> flag or something of that effect to the request structure so that we wouldnt
>>> fault when the swl/swr pairs were used in MIPS.
&g
. Same applies to caches if it
> have ECC (probably L2 or L3, L1 highly unlikely), but explicit partial
> load/stores are not very common and cached byte/half word stores goes to L1
> caches which usually have just parity which can be updated in the flight.
>
> - Original Message - Fr
If that's true, is this patch even relevant or can we just get rid of it?
Steve
On Wed, Jan 20, 2010 at 12:43 PM, Derek Hower wrote:
> It doesn't. I believe that StateMachine.cc is blown away in a later merge.
>
> On Wed, Jan 20, 2010 at 2:08 PM, Beckmann, Brad wrote:
>> I'm a little confused h
The commit message could use some elaboration here :-).
Also, I saw in a later patch that libruby_isReady() got deleted... was
it ever used in the interim? If not, can we just qfold that patch in
here and never add it to begin with?
Steve
On Tue, Jan 19, 2010 at 3:19 PM, Derek Hower wrote:
> #
As Brad already pointed out, it'd be better just to go back where this
code was commented out and remove it there. You ought to be able to
qfold this patch into the earlier one to achieve that.
Steve
On Tue, Jan 19, 2010 at 3:20 PM, Derek Hower wrote:
> # HG changeset patch
> # User Derek Hower
It looks like there are some unrelated changes to a couple of
config/*.rb files mixed in here... they ought to be in a separate
patch.
Steve
On Tue, Jan 19, 2010 at 3:20 PM, Derek Hower wrote:
> # HG changeset patch
> # User Derek Hower
> # Date 1263942696 21600
> # Node ID 21fbf0412e0d63246d10
See the calls to translateAtomic() in cpu/base_dyn_inst.hh.
Steve
On Wed, Jan 20, 2010 at 9:32 AM, Yuval Peress wrote:
> Hello,
>
> I am working on caches in M5's full system simulation using the o3 cpu.
> While working on the vport class (mem/vport.hh), I noticed a call to
> TheISA::vtophys(...
Has anyone used the BATCH_CMD facility in our SConstruct to run
compiles or regressions using LSF? If so, any patches you can share?
Thanks,
Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
On Tue, Jan 26, 2010 at 2:10 PM, nathan binkert wrote:
>> Has anyone used the BATCH_CMD facility in our SConstruct to run
>> compiles or regressions using LSF? If so, any patches you can share?
>
> I am very interested as well. I looked into this at one point and
> Gabe may have as well while he
changeset 22df98a968bf in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=22df98a968bf
description:
tests: added M5_TEST_PROGS environment variable
to allow override of global location for regression test binaries.
diffstat:
1 file changed, 2 insertions(+), 3 delet
changeset 5eb6e323b595 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5eb6e323b595
description:
ruby: get rid of obsolete, unused CustomTopology class.
diffstat:
3 files changed, 158 deletions(-)
src/mem/ruby/network/simple/CustomTopology.cc | 140
changeset a658c315512c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a658c315512c
description:
ruby: Convert most Ruby objects to M5 SimObjects.
The necessary companion conversion of Ruby objects generated by SLICC
are converted to M5 SimObjects in the f
changeset 2a1a3d916ca8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2a1a3d916ca8
description:
ruby: Make SLICC-generated objects SimObjects.
Also add SLICC support for state-machine parameter defaults
(passed through to Python as SimObject Param default
changeset c3a3c09af8be in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c3a3c09af8be
description:
scons: ignore blank lines in .slicc files
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/mem/protocol/SConscript |2 +-
diffs (12 lines):
diff -r 2a1a3d916
changeset c07cf29b5a33 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c07cf29b5a33
description:
ruby: Add support for generating topologies in Python.
diffstat:
7 files changed, 140 insertions(+), 148 deletions(-)
configs/example/memtest-ruby.py
changeset a9e3c07205a8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a9e3c07205a8
description:
ruby: Calculate system total memory capacity in Python
rather than in RubySystem object.
diffstat:
3 files changed, 12 insertions(+), 13 deletions(-)
configs/example
changeset 341a71fd2600 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=341a71fd2600
description:
Garnet: reorganize directory tree.
Rename the ruby/network/garnet-foo directories to garnet/foo.
Move the common NetworkHeader.hh file from garnet-fixed-pipeli
I'm looking at it now... I'm not sure exactly what the error is, but
it looks like it's running *only* the ruby tests now, and acting like
the non-ruby tests don't exist.
Steve
On Sun, Jan 31, 2010 at 11:24 AM, Beckmann, Brad wrote:
> I agree, I don't think it is working correctly. I don't have
otocol to not find any applicable configurations since
tests/SConscript is looking for a different default protocol.
I think the best way to fix this is to forget trying to have the test
configs track the 'default' Ruby protocol, but instead to always have
the protocol explicit in the conf
gt; From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
> Steve Reinhardt
> Sent: Sunday, January 31, 2010 4:40 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Cron
> /z/m5/regression/do-regression--scratch all
>
> OK, I believe it's a problem Brad
tests (that
really don't require a cache hierarchy at all) on all of the different
ruby protocol builds, but I don't think any of those are very long, so
that shouldn't be so bad to put up with.
Steve
On Sun, Jan 31, 2010 at 10:53 PM, Steve Reinhardt wrote:
> I'm not sure i
bit of effort into allowing multiple
> protocols to be compiled into the same binary. That would really fix
> the problem, right?
>
> Nate
>
> On Mon, Feb 1, 2010 at 8:46 AM, Steve Reinhardt wrote:
>> OK, I realize the idea I was originally thinking of didn't solve
;
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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-
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
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
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
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
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
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
'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
>
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
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
1 - 100 of 1287 matches
Mail list logo
