changeset ad9041185274 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ad9041185274
description:
stats: update stats for previous cset
Coherence protocol change basically got rid
of UpgradeReqs in L2 caches, other minor
related cache stat changes.
changeset d1ba390671ec in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d1ba390671ec
description:
cache: improve coherence handling of writebacks
If we write back an exclusive copy, we now mark it
as such, so the cache receiving the writeback can
ma
changeset 9782e93eeb63 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9782e93eeb63
description:
tests: print if output files match
Add '-s' flag to diff command generating outdiff
file so we have positive confirmation when
outputs match.
diffstat
changeset e44757c62695 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e44757c62695
description:
diff-out: clean up options
Make diff-out sort stats changes by percentage
by default, with '-a' to use current alpha sort
(instead of requiring '-p' to
I don't have any real comments other than to say that this seems like
a pretty good idea. Another thing to add to the list is callpal
emulation in SE mode. This is mostly for system calls, but there are
a couple of other pal calls that are emulated.
Nate
On Tue, Sep 21, 2010 at 9:02 PM, Gabri
This is basically to throw an idea out there in case it inspires or
enrages somebody enough to have a discussion, and to put it into the
group consciousness as a record for later.
One of the major differences between full system and syscall emulation
mode, and likely the only one that's ver
> To get back to this original problem (which I just ran into myself,
> making me pay more attention to this thread...): do we really need a
> separate enums package? It seems pretty unlikely you'll ever want the
> enums without the params, and while you might be able to use some
> params without
On Sun, Sep 19, 2010 at 1:39 AM, Ali Saidi wrote:
>
> On Sep 17, 2010, at 10:10 PM, Joel Hestness wrote:
>
>> Try simply internal.enums.timing, that should work.
>>
>> To use this, I had to also add 'import enums' to
>> src/python/m5/internal/__init__.py. It looks like this completely fixed the
>From memcpy's man page:
DESCRIPTION
The memcpy() function copies n bytes from memory area src to
memory area dest. The memory areas should not
overlap. Use memmove(3) if the memory areas do overlap.
So I think to play nice, we shouldn't copy even from a buffer to itself.
I don't
We could also just protect the case if (addr1 != addr2) I've thown that in
to make the error go away so I can get on with other errors... another two to
add to the list:
==5949== Conditional jump or move depends on uninitialised value(s)
==5949==at 0x9BB623: AlphaISAInst::Addl::execute(T
That memcpy issue is funky but it appears innocuous... note that the
src and dest are identical (not just overlapping) so it's really a
no-op. Looking at the code more closely, it appears to happen here:
if (mshr->isForward) {
// not a cache block request, but a response is ex
Well, there are several issues there that we need to fix. I just saw the
source/dest bug as well. Steve, any idea under what conditions this happens? I
couldn't quite trace through the code and I don't understand why the packet
that is attached to the mshr and the received packet should have the
>
> I would guess that the issues aren't related, but it's always difficult to
> be certain. Have you tried running it with valgrind?
>
> Valgrind shows an initialization error and what appears to be an
interesting memcpy bug in packet handling in the cache tags, but it doesn't
look like either are
13 matches
Mail list logo
