The problem we are having is something like this. With ARM there are some
incrementing loads/stores that do the following:
addr_tmp = Rm + Rn
Rt = MemoryLoad(addr_tmp)
Rn = addr_tmp
In the case of the atomic simple cpu this works fine because the Rn = addr is
protected by a if (fault ==
On 2010-06-06 12:34:28, Nilay Vaish wrote:
The changes seem
I have two observations
1. In several places we are using dynamic_cast. The patch under
consideration moves some of these to safe_cast and retains dynamic_cast at
other places. Should we not use safe_cast in all
I've only thought about this briefly, but here are a few quick reactions:
- PowerPC has updating ld/st instructions too. How are these handled?
Whatever we do, we should do the same thing for both.
- How would a real pipeline handle this, particularly for loads? In
that case you have two
1. In several places we are using dynamic_cast. The patch under consideration
moves some of these to safe_cast and retains dynamic_cast at other places.
Should we not use safe_cast in all places? This would avoid the checks that
dynamic_cast carries out when not running the debug version.
The commit notification email failed because I did the commit as user
'm5test', but it happened nonetheless:
http://repo.m5sim.org/m5/rev/111f36470db4
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
On Jun 6, 2010, at 4:53 PM, Steve Reinhardt wrote:
I've only thought about this briefly, but here are a few quick reactions:
- PowerPC has updating ld/st instructions too. How are these handled?
Whatever we do, we should do the same thing for both.
Tim, care to comment?
- How would a
I haven't looked at this in great detail (and don't plan to), but I'm
wondering: I don't know what the purpose of Allocator() was, but does it make
sense to replace it with FastAlloc rather than just leaving it to the default
allocator? I see where this would be a little more complicated
Hi everyone,
On 06/06/2010 18:59, Ali Saidi wrote:
On Jun 6, 2010, at 4:53 PM, Steve Reinhardt wrote:
I've only thought about this briefly, but here are a few quick reactions:
- PowerPC has updating ld/st instructions too. How are these handled?
Whatever we do, we should do the same thing
Timothy M Jones wrote:
Hi everyone,
On 06/06/2010 18:59, Ali Saidi wrote:
On Jun 6, 2010, at 4:53 PM, Steve Reinhardt wrote:
I've only thought about this briefly, but here are a few quick
reactions:
- PowerPC has updating ld/st instructions too. How are these handled?
Whatever we do,
Is there any particular reason that RUBY is a global build option, and
not a per-build one? (That is, I can't build MIPS_SE w/o Ruby and
then build ALPHA_SE or even ALPHA_SE_MOESI_hammer with Ruby in the
same build directory.) Nate, you're the one that added RUBY to
global_sticky_vars and not
OK, I see that not having it as a global option causes the check in
src/mem/ruby/SConsopts to fail, but I commented that out and things
seem OK.
Steve
On Sun, Jun 6, 2010 at 8:55 PM, Steve Reinhardt ste...@gmail.com wrote:
Is there any particular reason that RUBY is a global build option, and
11 matches
Mail list logo
