to:ni...@cs.wisc.edu]
Sent: Tuesday, January 04, 2011 12:03 PM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: Changing how CacheMemory interfaces with SLICC
Brad
Is there a reason why each action name follows the pattern _? The letters used are not
abbreviations of the action performed. Can w
Hi Nilay,
My responses are below:
> The main thing I would like to see improved is not having to differentiate
> between “entry†and “entry_ptr†in the .sm files. Am I correct
> that the only functions in the .sm files that are passed an
> “entry_ptr†are “is_valid_ptrâ€, “getCa
:
> Brad, which protocols work correctly with ruby random tester?
>
> On Tue, 21 Dec 2010, Beckmann, Brad wrote:
>
>> Hi Nilay,
>>
>> If I'm correctly reproducing your problem, I believe I know what the
>> issue is. However, before I try to fix it, I want
Behalf Of
Nilay Vaish
Sent: Tuesday, December 21, 2010 6:24 PM
To: M5 Developer List
Subject: Re: [m5-dev] Deadlock while running ruby_random_test.py
Brad, which protocols work correctly with ruby random tester?
On Tue, 21 Dec 2010, Beckmann, Brad wrote:
> Hi Nilay,
>
> If I&#x
Hi Nilay,
If I'm correctly reproducing your problem, I believe I know what the issue is.
However, before I try to fix it, I want to propose simply getting rid of the
MESI_CMP_directory. The more and more I look at that protocol, the more
problems I see. There are several design and logic iss
Hi Nilay,
I apologize for the delay, but I was mostly travelling / in meetings last week
and I didn't have a chance to review your patches and emails until this morning.
Overall, your patches are definitely solid steps in the right direction and
your profiling data sounds very promising. If yo
; lot of times where I've wished we had that since I accidentally broke
> something :-). I remember hearing that would be hard to do for some
> reason, though.
>
> Gabe
>
> Quoting "Beckmann, Brad" :
>
> > Hi Ali,
> >
> > I just synced with this
functions? I know the name of the machine can be accessed. But can the
> machine itself be accessed? I need one of the variables in the
> StateMachine object to know whether or not TBETable exists in this
> machine.
>
>
> Nilay
>
> On Wed, 8 Dec 2010, Beckmann, Brad wro
Hi Ali,
This is changset 7730 which also breaks all previous checkpoints because it
requires phsymem to serialize and unserialize the variable "_size".
Brad
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Ali Saidi
> Sent: Monday, N
Hi Ali,
I just synced with this changeset 7733, as well as changeset 7730, and I now
notice that the modifications to physical.cc break all previous checkpoints.
Can we put the lal_addr and lal_cid serialization and unserialization in a
conditional that tests for the ARM ISA? I welcome other
y itself. We can move that variable to
be part of the AbstractCacheEntry or we can combine it with the permission
variable which is already there in the AbstractCacheEntry class. I think lock
is only used in the implementation of LL/SC instructions.
Nilay
On Wed, 8 Dec 2010, Beckmann, Brad w
Done.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, December 07, 2010 4:43 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: Review Request: NDEBUG for Ruby Assert statement
Brad,
Since Steve and you have reviewed the patch, I guess we can commit it
isualize what change is going to have
what effect.
One question, should we use pointers to pass the cache entry around, or should
we make use of reference variables? Currently lookup functions return
references to cache entries.
Nilay
On Tue, 7 Dec 2010, Beckmann, Brad wrote:
> Hi Nila
a local variable.
>
> Nilay
>
> On Mon, 29 Nov 2010, Beckmann, Brad wrote:
>
>> Hi Nilay,
>>
>> I don't think we want to replace the implicit Address parameter
>> inside the state machines with the CacheEntry parameter, but we might
>> want to su
Hi Nilay,
I don't think we want to replace the implicit Address parameter inside the
state machines with the CacheEntry parameter, but we might want to supplement
the state machine functions to include both. I don't think we can replace the
Address parameter because certain transitions within
October 26, 2010 9:48 AM
To: M5 Developer List
Cc: Nilay Vaish; Beckmann, Brad; Steve Reinhardt
Subject: Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support
> I would prefer not to have the .sm DPRINTF calls look exactly like the c++
> calls. In particular, it seems
I see. When I suggested to Nilay to implement the print functions and remove
the operator<< functions, I was using M5's pkt print statements as loose
inspiration. I should have been more thorough in my investigation because I
know realize that there are a few M5 base objects that do the operat
Nilay, I apologize for the confusion here. It seems that Nate and I are
suggesting you go in two different directions in terms of the operator<<. I
personally wanted to get away from the operator<< overloading, so that Ruby
objects looked more similar to most M5 objects. Especially because mo
ay or another, this means fast-forwarding Ruby.
This is the area around which I'd like to invite discussion.
- Is quiescing Ruby the right way to implement functional access?
- What is the best way to go about fast-forwarding Ruby events?
Regards,
Dan
On Wed, Aug 18, 2010 at 1:18 PM, Beckmann,
Thanks for the heads up. There actually are a couple silly config
initialization errors that crept in while I was creating my final set patches a
couple weeks ago.
I'll be pushing two simple fixes momentarily.
Brad
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev
Thanks for heads up Gabe. Yep I missed that.
It turns out there a few things currently broken with the ruby config scripts.
I'll be pushing some changes momentarily.
Brad
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Gabe Black
> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Steve Reinhardt
> Sent: Thursday, August 19, 2010 3:03 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] TimingSimpleCPU, x86: sendSplitData packet sender
> states
>
> (That said, look
Hi All,
Yesterday a few of us from AMD and Wisconsin met and discussed the next tasks
for GEM5. Specifically there are a couple (possibly more?) new graduate
students at Wisconsin that are starting to ramp up in the simulator. While we
spent some time discussing short-term projects for the ne
Yep...that is the issue.
BTW, I did use "hg mv" for this patch.
Brad
-Original Message-
From: Nathan Binkert [mailto:n...@binkert.org]
Sent: Wednesday, August 11, 2010 7:54 PM
To: Default; Beckmann, Brad; Nathan Binkert
Subject: Re: Review Request: ruby: moved python prot
: Gabe Black [mailto:gabe.bl...@gmail.com] On Behalf Of Gabe Black
Sent: Sunday, August 15, 2010 2:16 PM
To: M5 Developer List
Cc: Beckmann, Brad; Nathan Binkert
Subject: Re: [m5-dev] Review Request: ruby: Resurrected Ruby's deterministic
tests
How about putting the stuff currently in memtest
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Beckmann, Brad
Sent: Wednesday, August 11, 2010 10:15 AM
To: M5 Developer List
Subject: Re: [m5-dev] Ruby Patches
I've addressed Nate's comments and I have a set of patch updates to post for
review. I noti
I've addressed Nate's comments and I have a set of patch updates to post for
review. I noticed that 'hg postreview' won't update the current patch but
instead will create new patches. I see that I can manually update the patches
on the reviewboard website, but for the number of patches I want
Hi Pritha,
I am aware of that specific problem. The current, checked-in version of Ruby
does not correctly handle load-locked and store-conditional instructions. I
have a patch that fixes that specific issue, as well as many other patches that
fix other issues, however I haven't found the tim
Hi Pritha,
The warnings you mentioned are expected and can be ignored as long as they only
complain about Ruby Sim Objects. The reason for them is the checkpoint you
created using normal ALPHA FS, only checkpointed the Sim Objects used by normal
ALPHA FS, but when a Ruby enabled system loads t
o start.
> Slave CPU 2 console command START
> SlaveCmd: restart FC310020 FC310020 vptb FFFE
> my_rpb FC018680 my_rpb_phys 18680
> SMP: Processor 3 failed to start.
> Brought up 2 CPUs
>
> My command line is
> ./build/ALPHA_F
py -t
--caches --l2cache -n 4 -b bodytrack
Thanks for your help..
Pritha
On Fri, Jul 2, 2010 at 11:04 AM, Beckmann, Brad
mailto: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
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 the one you mentioned. I'm
happy to help you out and determine what the problem may be. However, be
warned that I might not be able to immediately create and pus
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 pret
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-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 wha
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 as
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 releas
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
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 l
Hi Nate,
Sorry for the slow reply...thanks for your patience.
Your diff looks fine to me. Initially I was confused why you needed to add the
double colon as part of a type, but I now realize this doesn't change the
protocol specifications files at all. It simply allows the LiteralExprAST to
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 do
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 tho
> to support generic x86 locked operations anyway.
>
> Steve
>
> On Mon, Mar 22, 2010 at 9:03 AM, Beckmann, Brad
> 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 orig
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
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 Wiscon
] 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
at that ExecEnable bug discussion though, and I
> recall that problem... sad to see that after all the discussion we had
> almost a year ago the bug is still not fixed (as far as I can tell).
> This patch you made here does look like it could be addressing the
> same or a similar issue.
&g
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
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 [mail
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
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 [mailto:m5-dev
Because it is used to create a static array.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Thursday, March 18, 2010 4:43 PM
To: M5 Developer List
Subject: Re: [m5-dev] [PATCH 26 of 31] ruby: Changed the default
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 switc
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 R
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.
TimingSimpleCPU::sendData(R
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:
6 is value used by other dma controllers and is the same value that was used in
the old ruby lang config files. I'm just maintaining that consistency.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Thursday, M
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 [mailto:m5-dev-boun..
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:
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 t
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.
Makin
which made
>>> it inconsistent 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.
&
it in the config name. This will require moving
the existing *-ruby reference outputs, but it's more stable in the
long run. Brad and I can probably discuss this tomorrow and make it
happen.
Steve
2010/1/31 Steve Reinhardt :
> I'm looking at it now... I'm not sure exactly what
I agree, I don't think it is working correctly. I don't have access to
the Michigan server and I can't reproduce the error. Could someone send
out the do-regression script?
Thanks,
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Ga
updates
>
> There are only 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
> wrote:
> > Ah...I read it wrong. Let me rep
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
> T
ilto:m5-dev-boun...@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
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: m5-dev@m5s
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
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 [mailto:m5-dev-boun...@m5sim.o
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
> Se
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 S
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. Me
Hi All,
I have more patches that I would like everyone to review. I haven't yet
received any feedback on my last set of patches, so I'm going to hold
off on pushing them before Christmas. For those of you who haven't had
a chance yet to review the previous set, you can review both sets at
yo
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 Beh
Of course, absolutely.
I've been holding off sending them out for review because I fully expect they
will need to change after Derek checks in his changes. However, I understand
many are curious to see them and I would like to check them in before
Christmas, so I'll go ahead and send them out
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,
Bra
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
t
009, at 5:27 PM, "Beckmann, Brad" 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 en
lps.
Polina
On Tue, Dec 1, 2009 at 2:08 PM, Beckmann, Brad
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
associated L1 c
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 rec
I think my other responses cover this specific question, but your general point
is well taken. Calling destructors is not a normal usage scenario, so these
destructor fixes aren't a big deal. I added them because I wanted to reduce
the memory leak errors from valgrind.
Brad
-Original Me
I use this feature to fast-forward a specific number of instructions and then
take a checkpoint.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
nathan binkert
Sent: Wednesday, November 18, 2009 8:32 PM
To: M5 Developer List
Subje
I believe we can certainly prune some of these. CHIP and check_head can
definitely go. I forget what check_stop_slots was for. THIS may go as well
once we complete the configuration unification.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
Nate
On Thu, Nov 19, 2009 at 4:07 PM, Beckmann, Brad 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 specif
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 [mailto:m5-
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: m5-dev
No, it is not absolutely necessary to duplicate these files. Both files use
many of the same parameters. However, they construct the memory systems in
different ways, so they are not complete duplicates. Actually it would be
great if we could remove the duplication not only between memtest.py
-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
# Date 1257791384 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 28 of 31] ruby: Changes necessary to get the hammer
protocolto work in GEM5
# HG changeset patch
# User Brad Beckmann
# 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 30 of 31] ruby: Added a memory controller feature to
MOESIhammer
# HG changeset patch
# User Brad Beckmann
# Date 1257791384 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 29 of 31] ruby: Hammer ruby configuration support
# HG changeset patch
# User Brad Beckmann
# Date 1257791384 28800
# Node ID
-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
# 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
# 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 24 of 31] ruby: fix CacheMemory destructor
# HG changeset patch
# User Brad Beckmann
# Date 1257791383 28800
# Node ID
-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
# Date 1257791383 28800
# Node ID
-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
# Date 1257791383 28800
# Node ID
-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
# Date 1257791383 28800
# Node ID
-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
# Date 1257791383 28800
# Node ID
-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
# Date 1257791383 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 18 of 31] ruby: Removed unused action z_stall
# HG changeset patch
# User Brad Beckmann
# Date 1257791383 28800
# Node ID
101 - 200 of 249 matches
Mail list logo
