* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
*
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
Hi guys,
On Tue, May 19, 2015 at 6:04 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
On Tue, 19 May 2015, Sooraj Puthoor wrote:
On May 12, 2015, 8:47 p.m., Nilay Vaish wrote:
There are two problems I have with this patch. Firstly, it changes the
generally
accepted meaning of '*'. Secondly,
On May 19, 2015, 9:15 p.m., Brad Beckmann wrote:
Are there any more comments on this patch?
Overall I am fine with the patch. I think there are places where there is no
space
between the operator '+' and its operands.
- Nilay
---
On May 19, 2015, 9:15 p.m., Brad Beckmann wrote:
Are there any more comments on this patch?
Nilay Vaish wrote:
Overall I am fine with the patch. I think there are places where there
is no space
between the operator '+' and its operands.
I forgot to say one thing. Since I am
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2810/#review6364
---
Ship it!
Ship It!
- Nilay Vaish
On May 11, 2015, 10:19 p.m., Tony
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2758/#review6335
---
Ship it!
Ship It!
- Alexandru Dutu
On May 7, 2015, 10:54 a.m.,
On May 19, 2015, 9:35 a.m., Alexandru Dutu wrote:
src/cpu/kvm/base.cc, line 819
http://reviews.gem5.org/r/2761/diff/1/?file=44905#file44905line819
Instead of csprintf, would std::setbase(16) be a better choice here?
actually we prefer to move away from c++ streams and use the
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2760/#review6345
---
Ship it!
Ship It!
- Alexandru Dutu
On May 7, 2015, 10:55 a.m.,
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2797/#review6343
---
At a high-level, I like that you're breaking out the replacement
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2799/#review6344
---
Ship it!
Ship It!
- Jason Power
On May 11, 2015, 10:21 p.m., Tony
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2760/#review6330
---
src/cpu/kvm/vm.hh (line 143)
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2761/#review6331
---
src/cpu/kvm/base.cc (line 819)
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2794/#review6338
---
Any more comments on this patch? It sounds like the discussion as been
On May 15, 2015, 3:07 p.m., Nilay Vaish wrote:
src/mem/ruby/network/MessageBuffer.cc, line 320
http://reviews.gem5.org/r/2805/diff/1/?file=45061#file45061line320
Why is this change right? Why can we move messages from one structure
to another in zero time?
These structures are
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2806/#review6349
---
Any more comments on this patch?
- Brad Beckmann
On May 11, 2015,
On May 12, 2015, 10:09 p.m., Jason Power wrote:
I'm going to echo what Nilay has said in a other reviews: Could you give an
example of how this is used? Say, an example getNextState() function. I'm
having a hard time visualizing how this is supposed to work in a protocol.
Brad
Hi Brad and Tony,
I've attached an updated diff. Take a look at it and see what you think.
Instead of adding the code
num_sets = l2_cache.size / options.cacheline_size / l2_cache.assoc
repl = PseudoLRUReplacementPolicy(num_sets = num_sets,
On May 12, 2015, 8:47 p.m., Nilay Vaish wrote:
There are two problems I have with this patch. Firstly, it changes the
generally
accepted meaning of '*'. Secondly, it is adding another keyword to the
language
which is, in my opinion, not required. Instead, the transition construct
On Tue, 19 May 2015, Brad Beckmann wrote:
On May 14, 2015, 1:56 p.m., Nilay Vaish wrote:
I think it is not just enabling local variables for action blocks.
My understanding is that this patch allows declaration of local
variables without initialization. My question is would you not
know
On May 12, 2015, 9:24 p.m., Jason Power wrote:
src/mem/ruby/structures/CacheMemory.hh, line 137
http://reviews.gem5.org/r/2802/diff/1/?file=45052#file45052line137
Can you add a comment here describing what this function does? I don't
find it self explanatory from the function
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2759/#review6347
---
Will this wrapper encompass BaseKvmCPU::kvmInterrupt as well or is it
On May 14, 2015, 2:53 p.m., Nilay Vaish wrote:
First, why do you need both stallPort() and check_next_cycle()? Both are
going to call scheduleEvent(Cycles(1)).
Second, why not just expose scheduleEvent() function and let the protocol
author use it in whatever way they like.
Why
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2794/#review6360
---
Ship it!
I can be ok with this for now.
For future reference, I think
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2802/#review6350
---
Ship it!
Ship It!
- Jason Power
On May 15, 2015, 8:12 p.m., Tony
On Tue, 19 May 2015, Sooraj Puthoor wrote:
On May 12, 2015, 8:47 p.m., Nilay Vaish wrote:
There are two problems I have with this patch. Firstly, it changes the
generally
accepted meaning of '*'. Secondly, it is adding another keyword to the language
which is, in my opinion, not
On May 12, 2015, 10:09 p.m., Jason Power wrote:
I'm going to echo what Nilay has said in a other reviews: Could you give an
example of how this is used? Say, an example getNextState() function. I'm
having a hard time visualizing how this is supposed to work in a protocol.
Brad
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2790/#review6359
---
Ship it!
Ship It!
- Jason Power
On May 11, 2015, 10:23 p.m., Tony
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2810/#review6353
---
Are there any more comments on this patch?
- Brad Beckmann
On May 11,
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2764/#review6357
---
Ship it!
Ship It!
- Alexandru Dutu
On May 7, 2015, 11 a.m., Andreas
On Tue, 19 May 2015, Brad Beckmann wrote:
On May 14, 2015, 2:53 p.m., Nilay Vaish wrote:
First, why do you need both stallPort() and check_next_cycle()? Both are going
to call scheduleEvent(Cycles(1)).
Second, why not just expose scheduleEvent() function and let the protocol
author use
On Tue, 19 May 2015, Brad Beckmann wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2794/#review6338
---
Any more comments on this
changeset ecbab2522757 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=ecbab2522757
description:
ruby: Fix RubySystem warm-up and cool-down scope
The processes of warming up and cooling down Ruby caches are
simulation-wide
processes, not just
On Tue, 19 May 2015, Joel Hestness wrote:
My first instinct is that it's a very bad idea to do GPU coalescing in
the RubyPort. The RubyPort is a thin shim that already does too many
things (and poorly in a couple cases). However, without seeing the GPU
code, I expect it would be hard for
On Mon, 18 May 2015, Brad Beckmann wrote:
On May 14, 2015, 2:43 p.m., Joel Hestness wrote:
I agree with Nilay on this one. If there is a reason to have a pointer, then
the C++ code should export a pointer type. Brad, it seems you also agree. From
your response on review 2790 (
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2833/#review6334
---
Ship it!
Ship It!
- Alexandru Dutu
On May 18, 2015, 12:24 p.m.,
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
On Mon, 18 May 2015, Brad Beckmann wrote:
On May 18, 2015, 10:06 p.m., Nilay Vaish wrote:
I have asked this question before when Steve posted this patch several months
ago.
I am going to ask it again? Is it all right to buffer requests in the
Sequencer?
Do we know of CPU designs that do
On Tue, 19 May 2015, Brad Beckmann wrote:
Brad Beckmann wrote:
I think exceptions are needed because SLICC creates the AST in a single
pass. I certainly don't know how to do this in another way. Derek Hower could
provide you a more detailed response.
Nilay Vaish wrote:
I am also
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
On May 19, 2015, 5:26 p.m., Alexandru Dutu wrote:
src/cpu/kvm/vm.hh, line 146
http://reviews.gem5.org/r/2760/diff/1/?file=44903#file44903line146
Would it be useful/cleaner to specialize this class for x86 and move
CPUIDVector, MSRIndexVector and getSupportedCPUID into the derived
On May 14, 2015, 6:10 p.m., Joel Hestness wrote:
src/mem/slicc/symbols/StateMachine.py, line 629
http://reviews.gem5.org/r/2801/diff/1/?file=45050#file45050line629
I see. On my first pass here, I misread that this code allows arbitrary
expressions for setting buffer_size. You're
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
45 matches
Mail list logo
