in simulate (num_cycles=9223372036854775807) at
build/ALPHA_FS/sim/simulate.cc:73
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nathan
binkert
Sent: Wednesday, November 12, 2008 4:54 PM
To: Beckmann, Brad
Cc: M5 Developer List
Subject: Re: [m5-dev] changeset
Tushar and I see that you can run MemTest through ruby using the regression
tester interface, but we were hoping to run MemTest directly from the command
line. I see that configs/example/memtest.py allow you to configure the MemTest
cpu object from the command line, but it only seems to work
Hi All,
Tushar and I have noticed a few issues with GEM5 and we were wondering
if anyone had plans to fix them. If not, we'll go ahead and check in
fixes to the global repository. I just want to make sure we're not
stepping on anyone's toes.
- Fix SLICC so that protocol generated files are
Thanks Derek and Nate for the replies. Overall, it sounds like no one is
directly working on the four issues I outlined below, so I'll put them on my to
do list. The NetDest and DMA controller issues are most pressing, so I'll work
on those first. Later on I'll work on the SLICC errors and
Thanks Derek.
I think we should be consistent with how GEMS separates sequencer requests from
network requests and thus we should split them into two different types. The
DMA network requests should be specified in the protocol message file since
they interact with that particular protocol's
I was hoping that there was a better way to solve this...I'm glad you found it!
However I'm confused why you don't think MachineType::L1Cache is legal SLICC
code? SLICC can reference a particular machine type by simply removing a
colon, MachineType:L1Cache. This will translate to
As someone who is very familiar with how SLICC currently generates code,
I'm little concerned about changing the core of GEMS but maybe I just
need to understand what you are proposing in more detail. Sometimes
SLICC generation bugs can be hard bugs to find and I would be leery of
potentially
Great. Being able to diff the two sets a files will certainly ease debug.
I hope you don't mind me asking, but why does the fragility of generated code
matter? One should never modify generated code and only rarely look at it.
I'm interested to hear your ideas about how moving SLICC to python
I think the folks at Wisconsin can best speak about the MIF code generator. It
was used to formally verify the correctness of protocols. I'm not sure if any
current projects plan to use that support.
The CHECK_INVALID_RESOURCE_STALLS was something I created many years ago to
ensure that all
The parsing errors are much better. Thanks!
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Tuesday, August 04, 2009 9:38 AM
To: M5 Developer List
Subject: Re: [m5-dev] Scons cleaning
Yes, especially with the
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I wanted
to discuss the protocol directory issue in more detail. I'm completely fine
with recompiling all files when changing protocols. I would just like the
ability to have two different M5 binaries, using different
Hi All,
Attached is a patch I would like to check in that allows Ruby to support
a very large memory address space and high core count. Currently ruby
uses a flat array to store the memory state of the system. This works
well when the simulated system is roughly 4 GB or less, but is not
cache_size is zero?
-Derek
On Fri, Sep 11, 2009 at 6:09 PM, Beckmann, Brad brad.beckm...@amd.com wrote:
Hi All,
Attached is a patch I would like to check in that allows Ruby to support a
very large memory address space and high core count. Currently ruby uses a
flat array to store the memory
Darn...I was hoping -X would work. So by manually creating multiple patches,
you mean qnew a few almost empty patches and then cut-and-paste the one patch
into those new patch files, right?
It may be just me, but I have a hard time determining in real time when a
modification requires a new
Hi All,
I know a few people on this use the libm5_*.so and I was wondering if
you could describe the environment you have when building the .so. In
particular, is your $PYTHONPATH, $PYTHONHOME, and $LD_LIBRARY_PATH set,
and if so do they all point to the same place? Are any other
Actually I believe the problem is with the installation of python I'm pointing
to. When I point to any other installations of libpython.so, even different
installations of the same 2.5.1 version, it seems to work. I'm not sure what
is faulty with the particular installation, but I should have
Hi All,
I'm encountering an event scheduled in the past assertion error when
loading a checkpoint using ALPHA_FS. I believe the specific problem is
the MC146818 model schedules its RTC clock tick event for cycle
1, but its unserialized function doesn't reschedule it for
the
Steve and I have solved the bug. The solution fixes the MC146818
unserialize function and adds ISA serialize and unserialize function
calls to simple_thread.cc.
I'll push the patch momentarily.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Beckmann, Brad
Sent: Thursday, October 15, 2009 3:14 PM
To: M5 Developer List
Subject: Re: [m5-dev] Possible Bug in MC146818
Steve and I have solved the bug. The solution fixes the MC146818
unserialize function
I might be able to help with this, but I'm not sure exactly what the
problem is. It might be caused by a reference to the libruby_file
variable in ruby_se.py. I can't (or don't know how to) access
/z/m5/regression/regress-2009-10-18-03:00:01 to confirm, but
memtest-ruby is working for me with
, Oct 18, 2009 at 1:07 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
I might be able to help with this, but I'm not sure exactly what the
problem is. It might be caused by a reference to the libruby_file
variable in ruby_se.py. I can't (or don't know how to) access
/z/m5/regression/regress-2009
values to change, but we
only want them to change when we actually change something that should
affect them. She was going to verify that it made sense.
Nate
On Sun, Oct 18, 2009 at 12:09 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Actually, it looks like a reference miscorrelation error
Hi All,
In the process of adding full system support to Ruby I came across an
issue with an error message from the new python SLICC ast files. In
particular, the MemberExprAST didn't not generate the correct error
message. Instead I encountered the following python stack. The fix
seems
can really read them carefully right now.
Nate
On Mon, Nov 9, 2009 at 2:00 PM, nathan binkert n...@binkert.org wrote:
Is there a chance you can resend these so they're in individual
e-mails? It's tough to wade through this way.
Thanks,
Nate
On Mon, Nov 9, 2009 at 10:38 AM, Beckmann, Brad
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 01 of 31] ruby: Ruby memtest python script
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791381 28800
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 02 of 31] ruby: Ruby debug print fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791381 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 04 of 31] ruby: Ruby 64-bit address output fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 03 of 31] ruby: Ruby destruction fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382 28800
# Node ID
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 05 of 31] ruby: Added more info to bridge error message
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 07 of 31] ruby: Added error check for openning the ruby
configfile
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 06 of 31] ruby: Support for merging ALPHA_FS and ruby
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 08 of 31] ruby: included ruby config parameter ports per
core
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 09 of 31] m5: Added isValidSrc and isValidDest calls
topacket.hh
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 10 of 31] m5: Moved profile option since Simulation
depends onit
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 11 of 31] ruby: Fixed Directory memory destructor
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 12 of 31] ruby: getPort function fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382 28800
# Node ID
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 13 of 31] m5: fixed destructor to deschedule the
tickEvent andevent
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 17 of 31] m5: Added option to take a checkpoint at the
end ofsimulation
# HG changeset patch
# User Brad Beckmann brad.beckm
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 14 of 31] m5: removed master and slave deletions
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 19 of 31] ruby: slicc state machine error fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 18 of 31] ruby: Removed unused action z_stall
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 20 of 31] ruby: slicc action error fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 21 of 31] ruby: slicc method error fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 22 of 31] ruby: Added default names to message buffers
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 23 of 31] ruby: split CacheMemory.hh into a .hh and a
.cc
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 25 of 31] ruby: cache configuration fix to use bytes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 24 of 31] ruby: fix CacheMemory destructor
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 26 of 31] ruby: returns the number of LLC needed for
broadcast
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 27 of 31] ruby: added the original hammer protocols from
oldruby
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 29 of 31] ruby: Hammer ruby configuration support
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791384
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 30 of 31] ruby: Added a memory controller feature to
MOESIhammer
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 28 of 31] ruby: Changes necessary to get the hammer
protocolto work in GEM5
# HG changeset patch
# User Brad Beckmann brad.beckm
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 31 of 31] ruby: MOESI hammer support for DMA reads and
writes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
Actually, if I remember correctly, the idx of -1 is not an error, but is the
value passed in for the functional port. Yes, I absolutely agree this is ugly,
but fortunately this along with all of rubymem goes away with the new
configuration system.
Brad
-Original Message-
From:
All of these destructor fixes were problems I encountered when I called all the
sim_object destructors on M5 exit. (I can send you the simple patch if you
like.)
I'll send out details on the specific error later today.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
On Thu, Nov 19, 2009 at 4:07 PM, Beckmann, Brad brad.beckm...@amd.com wrote:
All of these destructor fixes were problems I encountered when I called all
the sim_object destructors on M5 exit. (I can send you the simple patch if
you like.)
I'll send out details on the specific error later today
Hi,
This question is mostly for Derek, but I figured that others at
Wisconsin may be able to answer it as well. I notice that the current
Ruby atomic support requires the sequencer to have direct access to its
associated L1 cache controller, rather than just via the mandatory
queue. Derek
On Tue, Dec 1, 2009 at 2:08 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Hi,
This question is mostly for Derek, but I figured that others at
Wisconsin may be able to answer it as well. I notice that the current
Ruby atomic support requires the sequencer to have direct access to its
, Beckmann, Brad brad.beckm...@amd.com wrote:
Thanks Polina.
No rush, but when do you suspect you’ll check in that code? Steve and
I have made a lot of progress on the unified configuration changes and I’m
hoping to send out another series of patches by the end
Thanks Nate.
Yes, the scheduleClock() function you mentioned would definitely help
implementing the complete solution. Once I'm done with the initial
RubyEvent wrapper solution, I can send out our patches for review. Once
I verify and checkin those patches, using the scheduleClock() seems like
Hi Derek,
Do you need any more help merging your outstanding changes? I'm almost
ready to check in my changes that unify configuration and the
eventqueue. However, I want to give you the opportunity to check in
your changes first.
Let me know if there is anything I can do to help.
Thanks,
Yes, I didn't mean to imply that we need to create a libruby tester. As you
said, what we really need is just a way to change Ruby's API while ensuring we
don't break libruby functionality.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Thanks Nate for reviewing all of our patches.
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 before
checking it.
I failed to mention earlier that the parameter is used in the protocol files so
it isn't just simple C++. However, it is simple enough to make SLICC generate
the correct C++ since RubySystem has static functions that provide the block
size bits. Once these functions are no longer static, the
The main reason not to delete the old config files now is libruby has yet to be
updated. I wanted to hear Derek and others opinion before I removed the files.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of nathan binkert
Sent:
Hi Derek,
As Nate suggested, please remove unwanted code instead of commenting it
out. That way it becomes clearer to me what changes I really need to
address when I merge in our patches.
Thanks,
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
I'm a little confused here. Are you still using the old c++ version of
slicc or are you using the new python version?
I didn't think StateMachine.cc even existed now.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Derek Hower
Just curious. Why can't you use the MESI_CMP_directory or
MOESI_CMP_directory protocols in this config file?
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Derek Hower
Sent: Tuesday, January 19, 2010 3:20 PM
To:
...@m5sim.org] On
Behalf Of Derek Hower
Sent: Wednesday, January 20, 2010 12:42 PM
To: M5 Developer List
Subject: Re: [m5-dev] [PATCH 18 of 43] ruby: configuration updates
You can. In fact, that is the only two you can use with it.
On Wed, Jan 20, 2010 at 2:12 PM, Beckmann, Brad brad.beckm
Oh, is that because those are the only two protocols that support the new
atomic implementation?
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Beckmann, Brad
Sent: Wednesday, January 20, 2010 1:35 PM
To: M5 Developer List
three protocols that work (prior to your changes). Two
of them work with this configuration, and one, MI_example, is not a
two level protocol.
On Wed, Jan 20, 2010 at 3:34 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Ah...I read it wrong. Let me rephrase my question. So why can you
only
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 brad.beckm...@amd.com
wrote:
I agree, I don't think it is working correctly. I don't have
with what you assumed it was in tests/SConscript.
Anyway, I think the fix I suggested that completely removes any
dependence on the default value in the test system is more robust and
what we should do in the long run.
Steve
On Sun, Jan 31, 2010 at 10:33 PM, Beckmann, Brad brad.beckm...@amd.com
Hi All,
I just had a question about the default pal binary for ALPHA_FS. Would
it be possible for us to change the default pal binary to tsb_osfpal? I
know that tsb_osfpal binary does represent a real system, but the
ts_osfpal binary is limited to 4 cores, which isn't very interesting.
Hi Nate,
I don't have an opinion on where the refs go and how that relates to the
UnitTest subclass, but I do want to second a couple of the items you mentioned.
I really like the idea of explicitly having users specify an existence of a
test rather than just relying on the ref directory and
Hi Nate,
I have a lot of outstanding patches in our MQ that will likely conflict with
your style pass. I can probably send my patches out for review on Thursday.
It would be great if I could get them in before your commit. Will that work
for you?
Brad
-Original Message-
From:
Actually this patch is from Tushar Krishna. I did notice your recent style
patch, but I failed to notice that Tushar's patch didn't follow that. I
completely agree with your comments. I'll make the changes.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
Hi Steve,
No, SLICC does not have a logical negation operator.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Steve Reinhardt
Sent: Thursday, March 18, 2010 4:15 PM
To: M5 Developer List
Subject: Re: [m5-dev] [PATCH 03 of 31] ruby:
I don't have exact Valgrind stack anymore, but below is the approximate call
stack (it is actually a subset of another call stack that I wasn't able to
completely solve...more on that later). Basically if I remember correctly, the
request is deleted within sendData.
Yes, I uncommented some code that was commented out, but I'm not sure why it
was commented out in the first place. I would rather see it all uncommented,
but it would be great if someone at Wisconsin could say on why it was
originally commented out first.
SparseMemory is only integrated with
Sure, I can fold it. In general, I try to be conservative in my folding rather
than be aggressive. It is always easier to qfold than to split a patch out.
I would prefer to use ruby stats for the time being just because I'm more
familiar with it. I'll make the switch when ruby makes the
Topologies and protocols are separate, but both involve slicc generated
objects. Since they can be intermixed, I think it makes sense for them both to
be at the same directory level from a configuration perspective.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
My preference is if a call can't fit on one line, then each param should be on
a separate line. Otherwise long function calls can be hard to read and it is
easier to maintain consistent spacing. Overall, I supposes it just depends if
you prefer density or spacing.
Brad
Here's another style
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?
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org
I think the thing to keep in mind is that this default value is only used to
generate the controller SimObject py file. I don't want to add a constant
because that leads to the thing I want to avoid the most...having more than 1
way to specify defaults. In the end, I think the right way to do
it could be addressing the
same or a similar issue.
Steve
On Thu, Mar 18, 2010 at 6:56 PM, Beckmann, Brad brad.beckm...@amd.com wrote:
I don't have exact Valgrind stack anymore, but below is the approximate call
stack (it is actually a subset of another call stack that I wasn't able
] Ruby updates and simple perf.
optimizations
On Thu, Mar 18, 2010 at 7:00 PM, Beckmann, Brad brad.beckm...@amd.com 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
I did see your comments on the isReadWrite check and that is why I added the
Fix Me comment. The problem is I did not originally add the line and I have
no way of testing any changes to this functionality. I assume this is needed
by the libruby interface and I'm expecting the folks at
I'm curious why a few tests last night showed stats differences. When I
locally run the regression tester, the only large statistically differences I
see are in the host_inst_rate. I don't have direct access to the regression
machine and I just want to make sure that I haven't missed anything
, Beckmann, Brad brad.beckm...@amd.com
wrote:
I did see your comments on the isReadWrite check and that is why I
added the Fix Me comment. The problem is I did not originally add
the line and I have no way of testing any changes to this
functionality. I assume this is needed by the libruby
Hi Nate,
I just pulled in these changes and I noticed that you only applied your style
pass on a subset of ruby directories. Is there a reason for that?
Specifically, you didn't modify the following directories: network, profiler,
recorder, storebuffer, and tester. I realize that some of
I have seen those same Valgrind errors as well and I've tried to fix them with
little success. When I looked into the problem, it appeared to me that
Valgrind thought the misc reg space was not initialized, but I thought it was
when I stepped through tlb initialization using the debugger. I
Just a quick comment from the Peanut Gallery. :)
Several weeks ago I noticed the same issue with the Ruby Port's timing port and
made a similar change to Ruby as the change described below. Though it is a
little invasive to include the clock with every MemObject, it is rather
confusing to
Hi Ali,
We are still actively working on GEM5 support, but we don't have a particular
release date in mind. Both SE and FS work a some level, but exactly what works
depends on the particular protocol. There are several issues that still need
to be address with the most fundamental being that
Hi Pritha,
As you suspected, the wiki page is out-of-date and many of those initial
integration tasks are completed though not nearly in the time estimated. :)
The integration is progressing well and many other tasks not listed have been
completed as well. However, we are not ready to
Hi Nilay,
Please excuse the slow reply. Here is my perspective of what is left to for
Ruby.
Right now I have internal patches that re-enable the cache warmup tracing
capability, remove recycle requests, and incorporate several other bug fixes.
I plan to soon add uncacheable access support
-boun...@m5sim.org] On
Behalf Of Beckmann, Brad
Sent: Wednesday, June 16, 2010 11:38 AM
To: M5 Developer List
Subject: Re: [m5-dev] Ruby Todo List
Hi Nilay,
Please excuse the slow reply. Here is my perspective of what is left
to for Ruby.
Right now I have internal patches that re
Hi Nate,
As you can see by the Reviewboard emails, I reviewed 3 of your 4 patches.
However before I complete my review on your map patches, I want to inline my
comments into the diff as you suggested below. I noticed that I could download
the diff and manually insert my comments, but I'm
--caches --l2cache -n 4 -b bodytrack
Thanks for your help..
Pritha
On Fri, Jul 2, 2010 at 11:04 AM, Beckmann, Brad
brad.beckm...@amd.commailto:brad.beckm...@amd.com wrote:
Hi Pritha,
In general, the protocols in M5 aren't quite ready for primetime and I
wouldn't be surprised if you encounter bugs like
: Processor 3 failed to start.
Brought up 2 CPUs
My command line is
./build/ALPHA_FS_MOESI_hammer/m5.opt ./configs/example/ruby_fs.py -t
--caches --l2cache -n 4 -b bodytrack
Thanks for your help..
Pritha
On Fri, Jul 2, 2010 at 11:04 AM, Beckmann, Brad
brad.beckm
1 - 100 of 219 matches
Mail list logo
