[gem5-dev] changeset in gem5: Mem: Use sysconf to get the page size instead...
changeset e39a9c0493ad in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=e39a9c0493ad description: Mem: Use sysconf to get the page size instead of the PAGE_SIZE macro. diffstat: src/mem/physical.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff -r 1810956fa5dc -r e39a9c0493ad src/mem/physical.cc --- a/src/mem/physical.cc Tue Jun 07 00:46:54 2011 -0700 +++ b/src/mem/physical.cc Wed Jun 08 00:57:50 2011 -0700 @@ -90,7 +90,7 @@ int fd = open(params()->file.c_str(), O_RDONLY); _size = lseek(fd, 0, SEEK_END); lseek(fd, 0, SEEK_SET); -pmemAddr = (uint8_t *)mmap(NULL, roundUp(size(), PAGE_SIZE), +pmemAddr = (uint8_t *)mmap(NULL, roundUp(size(), sysconf(_SC_PAGESIZE)), PROT_READ | PROT_WRITE, map_flags, fd, 0); } ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
= Statistics differences =* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. = Statistics differences =* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-at
Re: [gem5-dev] [m5-dev] Review Request: stats: move code that loops over all stats into python
Hi, I'm trying to call a global function implemented in C++ from a function in the Python __init__.py file, how can I do that? Is that a good example that I can follow? Thanks, William -Original Message- From: gem5-dev-boun...@m5sim.org [mailto:gem5-dev-boun...@m5sim.org] On Behalf Of nathan binkert Sent: 06 June 2011 22:07 To: gem5 Developer List Cc: M5 Developer List Subject: Re: [gem5-dev] [m5-dev] Review Request: stats: move code that loops over all stats into python > Where in the code is the signal from "kill -USR1" handled to dump stats? % grep -nR USR1 src src/sim/init.cc:97:signal(SIGUSR1, dumpStatsHandler); ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] [m5-dev] Review Request: stats: move code that loops over all stats into python
> I'm trying to call a global function implemented in C++ from a function in > the Python __init__.py file, how can I do that? Is that a good example that I > can follow? Just add your function foo() to src/python/swig/core.i and then you can access it from m5.internal.core.foo() Most of the functions in core.i are examples for you. ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The
main function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
> On Wed, 8 Jun 2011, Jack Harvard wrote:
>
>> When you declare your function private, you can't use instance.function() to
>> access it. Is it generating a compile time error?
>>
>> On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
>>
>>> Consider the following class declarations --
>>>
>>> class A
>>> {
>>> public:
>>> virtual void function() = 0;
>>> };
>>>
>>> class B : public A
>>> {
>>> private:
>>> void function();
>>> }
>>>
>>> int main()
>>> {
>>> B b;
>>> b.function();
>>> }
>>>
>>> Will this code compile correctly?
>>>
>>> --
>>> Nilay
>
> I should say that my example program was not what I intended it to be. The
> main function should look like --
>
> int main()
> {
> B* b = new B();
> A* a = b;
> a->function();
> return 0;
> }
>
> Now what would happen?
This compiles. However, if you do b->function(), you would get the same error
as your last example, due to the same reason.
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] changeset in m5: scons: rename TraceFlags to DebugFlags
> Why not just let TraceFlags be interpreted as DebugFlags, so TraceFlags still > works for users. For better or worse, I renamed trace flags to debug flags and I should have changed the name of TraceFlags to DebugFlags when I did that, so this was just correcting that and removing an inconsistency. You can just do TraceFlags = DebugFlags in your sconscript to make it continue to work. I don't think many people have added TraceFlags and even if they did, it's not much effort to fix. Nate ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
This compiles. However, if you do b->function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though
function() is private for class B, still it gets invoked using the pointer
from class A. I was not aware of this before.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
> On Wed, 8 Jun 2011, Jack Harvard wrote:
>
>>
>>
>> On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
>>
>>> On Wed, 8 Jun 2011, Jack Harvard wrote:
>>>
When you declare your function private, you can't use instance.function()
to access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
> Consider the following class declarations --
>
> class A
> {
> public:
> virtual void function() = 0;
> };
>
> class B : public A
> {
> private:
> void function();
> }
>
> int main()
> {
> B b;
> b.function();
> }
>
> Will this code compile correctly?
>
> --
> Nilay
>>>
>>> I should say that my example program was not what I intended it to be. The
>>> main function should look like --
>>>
>>> int main()
>>> {
>>> B* b = new B();
>>> A* a = b;
>>> a->function();
>>> return 0;
>>> }
>>>
>>> Now what would happen?
>>
>> This compiles. However, if you do b->function(), you would get the same
>> error as your last example, due to the same reason.
>>
>
> It compiles and executes fine. What surprises me is that even though
> function() is private for class B, still it gets invoked using the pointer
> from class A. I was not aware of this before.
Overriding and access visibility is orthogonal, you use class A pointer to
access its public function.
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
This compiles. However, if you do b->function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though function()
is private for class B, still it gets invoked using the pointer from class A. I
was not aware of this before.
Overriding and access visibility is orthogonal, you use class A pointer to
access its public function.
I won't term this is a overriding, the function that will be called would
be the one defined in class B, as 'function()' is a virtual member of
class A. But then, 'function()' is private to class B, so I would expect
some error to occur. I think the reason is that visibility is tested only
at compile time and never at run time.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On 9 Jun 2011, at 00:10, Nilay Vaish wrote:
> On Wed, 8 Jun 2011, Jack Harvard wrote:
>
>>
>> On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
>>
>>> On Wed, 8 Jun 2011, Jack Harvard wrote:
>>>
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
> On Wed, 8 Jun 2011, Jack Harvard wrote:
>
>> When you declare your function private, you can't use
>> instance.function() to access it. Is it generating a compile time error?
>>
>> On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
>>
>>> Consider the following class declarations --
>>>
>>> class A
>>> {
>>> public:
>>> virtual void function() = 0;
>>> };
>>>
>>> class B : public A
>>> {
>>> private:
>>> void function();
>>> }
>>>
>>> int main()
>>> {
>>> B b;
>>> b.function();
>>> }
>>>
>>> Will this code compile correctly?
>>>
>>> --
>>> Nilay
>
> I should say that my example program was not what I intended it to be.
> The main function should look like --
>
> int main()
> {
> B* b = new B();
> A* a = b;
> a->function();
> return 0;
> }
>
> Now what would happen?
This compiles. However, if you do b->function(), you would get the same
error as your last example, due to the same reason.
>>>
>>> It compiles and executes fine. What surprises me is that even though
>>> function() is private for class B, still it gets invoked using the pointer
>>> from class A. I was not aware of this before.
>>
>> Overriding and access visibility is orthogonal, you use class A pointer to
>> access its public function.
>
> I won't term this is a overriding, the function that will be called would be
> the one defined in class B, as 'function()' is a virtual member of class A.
> But then, 'function()' is private to class B, so I would expect some error to
> occur. I think the reason is that visibility is tested only at compile time
> and never at run time.
It's still overriding for the function() defined in B which is overriding the
function defined in base class A (whether it's defined as virtual or pure
virtual). In C++ it's allowed to override with a private member. That means you
can only call it via a pointer or reference to the base. This is occasionally
useful (eg if the base is a private one), but it isn't very common in my
experience.
(A long, long time ago there were rules in C++ like those in Java to
prevent derived classes reducing the visibility of members. They were
abandoned because they got in the way of reasonable code.)
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/#review1301 --- Ship it! This looks fine to me. I assume that if a controller doesn't include a setPermission or getPermission function, the compiler error message is the same as when a controller doesn't specify a getState function. Correct? - Brad On 2011-06-06 14:45:22, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/684/ > --- > > (Updated 2011-06-06 14:45:22) > > > Review request for Default. > > > Summary > --- > > Ruby: Correctly set access permissions for directory entries > The access permissions for the directory entries are not being set correctly. > This is because pointers are not used for handling directory entries. > function. get and set functions for access permissions have been added to the > Controller state machine. The changePermission() function provided by the > AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC > code once again. The set_permission() functionality has been removed. > > NOTE: Each protocol will have to define these get and set functions in order > to compile successfully. > > > Diffs > - > > src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 > src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 > src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 > src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 > src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 > src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 > src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 > > Diff: http://reviews.m5sim.org/r/684/diff > > > Testing > --- > > Passes regression tests and 1 loads with ruby random tester. > > > Thanks, > > Nilay > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
> On 2011-06-08 17:11:26, Brad Beckmann wrote: > > This looks fine to me. I assume that if a controller doesn't include a > > setPermission or getPermission function, the compiler error message is the > > same as when a controller doesn't specify a getState function. Correct? Currently SLICC does not output any error if set/getState() or set/getAccessPermission() are missing. But I have patch in the queue which enables catching these errors in SLICC. For now GCC outputs that a particular function has not been implemented. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/#review1301 --- On 2011-06-06 14:45:22, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/684/ > --- > > (Updated 2011-06-06 14:45:22) > > > Review request for Default. > > > Summary > --- > > Ruby: Correctly set access permissions for directory entries > The access permissions for the directory entries are not being set correctly. > This is because pointers are not used for handling directory entries. > function. get and set functions for access permissions have been added to the > Controller state machine. The changePermission() function provided by the > AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC > code once again. The set_permission() functionality has been removed. > > NOTE: Each protocol will have to define these get and set functions in order > to compile successfully. > > > Diffs > - > > src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 > src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 > src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 > src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 > src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 > src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 > src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 > > Diff: http://reviews.m5sim.org/r/684/diff > > > Testing > --- > > Passes regression tests and 1 loads with ruby random tester. > > > Thanks, > > Nilay > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: Ruby: Correctly set access permissions for di...
changeset 30daf1dd5c91 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30daf1dd5c91
description:
Ruby: Correctly set access permissions for directory entries
The access permissions for the directory entries are not being set
correctly.
This is because pointers are not used for handling directory entries.
function. get and set functions for access permissions have been added
to the
Controller state machine. The changePermission() function provided by
the
AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC
code once again. The set_permission() functionality has been removed.
NOTE: Each protocol will have to define these get and set functions in
order
to compile successfully.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 20
src/mem/protocol/MESI_CMP_directory-L2cache.sm | 21 -
src/mem/protocol/MESI_CMP_directory-dir.sm | 15 ++-
src/mem/protocol/MESI_CMP_directory-dma.sm | 7 +++
src/mem/protocol/MI_example-cache.sm | 20
src/mem/protocol/MI_example-dir.sm | 15 +++
src/mem/protocol/MI_example-dma.sm | 7 +++
src/mem/protocol/MOESI_CMP_directory-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-L2cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-dir.sm| 14 ++
src/mem/protocol/MOESI_CMP_directory-dma.sm| 7 +++
src/mem/protocol/MOESI_CMP_token-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_token-L2cache.sm| 15 +++
src/mem/protocol/MOESI_CMP_token-dir.sm| 15 ++-
src/mem/protocol/MOESI_CMP_token-dma.sm| 7 +++
src/mem/protocol/MOESI_hammer-cache.sm | 20
src/mem/protocol/MOESI_hammer-dir.sm | 15 ++-
src/mem/protocol/MOESI_hammer-dma.sm | 7 +++
src/mem/protocol/Network_test-cache.sm | 7 +++
src/mem/protocol/Network_test-dir.sm | 7 +++
src/mem/protocol/RubySlicc_Types.sm| 8 ++--
src/mem/ruby/slicc_interface/AbstractController.hh | 4
src/mem/slicc/ast/MethodCallExprAST.py | 8 +++-
src/mem/slicc/symbols/StateMachine.py | 17 -
24 files changed, 296 insertions(+), 20 deletions(-)
diffs (truncated from 604 to 300 lines):
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 11:58:09
2011 -0500
@@ -183,6 +183,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L1_TBEs[addr];
+if(is_valid(tbe)) {
+ return L1Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L1Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L1Cache_State_to_permission(state));
+}
+ }
+
Event mandatory_request_type_to_event(RubyRequestType type) {
if (type == RubyRequestType:LD) {
return Event:Load;
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 11:58:09
2011 -0500
@@ -202,7 +202,6 @@
return L2Cache_State_to_string(getState(tbe, cache_entry, addr));
}
- // when is this called
void setState(TBE tbe, Entry cache_entry, Address addr, State state) {
// MUST CHANGE
@@ -215,6 +214,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L2_TBEs[addr];
+if(is_valid(tbe)) {
+ return L2Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L2Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L2Cache_State_to_permission(state));
+}
+ }
+
Event L1Cache_request_type_to_event(CoherenceRequestType type, Address addr,
MachineID requestor, Entry cache_entry) {
if(type == CoherenceRequestType:GETS) {
diff -r e39a9c0493ad -r 30daf1dd5c91 src/mem/protoco
Re: [gem5-dev] Query on inheritance and virtual functions
Quoting Jack Harvard :
On 9 Jun 2011, at 00:10, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use
instance.function() to access it. Is it generating a compile
time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it
to be. The main function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
This compiles. However, if you do b->function(), you would get
the same error as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even
though function() is private for class B, still it gets invoked
using the pointer from class A. I was not aware of this before.
Overriding and access visibility is orthogonal, you use class A
pointer to access its public function.
I won't term this is a overriding, the function that will be called
would be the one defined in class B, as 'function()' is a virtual
member of class A. But then, 'function()' is private to class B, so
I would expect some error to occur. I think the reason is that
visibility is tested only at compile time and never at run time.
It's still overriding for the function() defined in B which is
overriding the function defined in base class A (whether it's
defined as virtual or pure virtual). In C++ it's allowed to override
with a private member. That means you
can only call it via a pointer or reference to the base. This is
occasionally useful (eg if the base is a private one), but it isn't
very common in my experience.
(A long, long time ago there were rules in C++ like those in Java to
prevent derived classes reducing the visibility of members. They were
abandoned because they got in the way of reasonable code.)
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Guys, lets try to keep conversations on the list related to gem5 please.
Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Single Header File for Debug Flags
What do people (mostly Nate) think about having a single header file for all debug flags? Instead of "#include "debug/MyFlag.hh" for every flag you want in a DPRINTF, you could say "#include "debug/debugflags.hh" and that would cover all the debug flags available for DPRINTF. Would that (the old way?) not be more desirable then the new way of including debug flags? Are there infrastructure things that make this complicated? -- - Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Single Header File for Debug Flags
> What do people (mostly Nate) think about having a single header file for all > debug flags? > > Instead of "#include "debug/MyFlag.hh" for every flag you want in a DPRINTF, > you could say "#include "debug/debugflags.hh" and that would cover all the > debug flags available for DPRINTF. > > Would that (the old way?) not be more desirable then the new way of > including debug flags? Are there infrastructure things that make this > complicated? The whole reason I changed the flags around was to avoid the centralized file :) The main problem with the centralized file is that if you add or remove a flag, you have to recompile just about everything. There is no reason that you couldn't do localized includes for a set of flags though. For example, you could add a file to the src/cpu/inorder directory called debugflags and include the few debug flags that you want and that way only the inorder CPU would be rebuilt if you added a flag to it. Adding the centralized file back wouldn't be quite as bad as it was before since it would only be a centralized .hh file and not a centralized .cc file (which makes doing things like adding a flag for a unit test a real problem.) I'm pretty sure it's not worth it though and the localized files that include a bunch of flags for each CPU model are probably as much as anyone really needs. Nate ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Single Header File for Debug Flags
Oh, and I forgot. Compound flags generate a header file as well. debug/O3CPUAll.hh for example would have all of the flags that O3CPUAll covers On Wed, Jun 8, 2011 at 9:40 PM, nathan binkert wrote: >> What do people (mostly Nate) think about having a single header file for all >> debug flags? >> >> Instead of "#include "debug/MyFlag.hh" for every flag you want in a DPRINTF, >> you could say "#include "debug/debugflags.hh" and that would cover all the >> debug flags available for DPRINTF. >> >> Would that (the old way?) not be more desirable then the new way of >> including debug flags? Are there infrastructure things that make this >> complicated? > > The whole reason I changed the flags around was to avoid the > centralized file :) The main problem with the centralized file is > that if you add or remove a flag, you have to recompile just about > everything. There is no reason that you couldn't do localized > includes for a set of flags though. For example, you could add a file > to the src/cpu/inorder directory called debugflags and include the few > debug flags that you want and that way only the inorder CPU would be > rebuilt if you added a flag to it. Adding the centralized file back > wouldn't be quite as bad as it was before since it would only be a > centralized .hh file and not a centralized .cc file (which makes doing > things like adding a flag for a unit test a real problem.) I'm pretty > sure it's not worth it though and the localized files that include a > bunch of flags for each CPU model are probably as much as anyone > really needs. > > Nate > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Single Header File for Debug Flags
Well, I guess the recompilation tradeoff is worth the temporary annoyance of adding the specific debug flag header file everywhere. I'm also hoping that the new changes will allow us to eventually make compound flags of compound flags. On Thu, Jun 9, 2011 at 12:42 AM, nathan binkert wrote: > Oh, and I forgot. Compound flags generate a header file as well. > debug/O3CPUAll.hh for example would have all of the flags that > O3CPUAll covers > > On Wed, Jun 8, 2011 at 9:40 PM, nathan binkert wrote: > >> What do people (mostly Nate) think about having a single header file for > all > >> debug flags? > >> > >> Instead of "#include "debug/MyFlag.hh" for every flag you want in a > DPRINTF, > >> you could say "#include "debug/debugflags.hh" and that would cover all > the > >> debug flags available for DPRINTF. > >> > >> Would that (the old way?) not be more desirable then the new way of > >> including debug flags? Are there infrastructure things that make this > >> complicated? > > > > The whole reason I changed the flags around was to avoid the > > centralized file :) The main problem with the centralized file is > > that if you add or remove a flag, you have to recompile just about > > everything. There is no reason that you couldn't do localized > > includes for a set of flags though. For example, you could add a file > > to the src/cpu/inorder directory called debugflags and include the few > > debug flags that you want and that way only the inorder CPU would be > > rebuilt if you added a flag to it. Adding the centralized file back > > wouldn't be quite as bad as it was before since it would only be a > > centralized .hh file and not a centralized .cc file (which makes doing > > things like adding a flag for a unit test a real problem.) I'm pretty > > sure it's not worth it though and the localized files that include a > > bunch of flags for each CPU model are probably as much as anyone > > really needs. > > > > Nate > > > ___ > gem5-dev mailing list > gem5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: sparc: compilation fixes for inorder
changeset 77d12d8f7971 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=77d12d8f7971
description:
sparc: compilation fixes for inorder
Add a few constants and functions that the InOrder model wants for
SPARC.
* * *
sparc: add eaComp function
InOrder separates the address generation from the actual access so give
Sparc that functionality
* * *
sparc: add control flags for branches
branch predictors and other cpu model functions need to know specific
information
about branches, so add the necessary flags here
diffstat:
src/arch/sparc/isa/decoder.isa | 6 +-
src/arch/sparc/isa/formats/branch.isa | 5 ++
src/arch/sparc/isa/formats/mem/basicmem.isa | 6 ++
src/arch/sparc/isa/formats/mem/swap.isa | 2 +-
src/arch/sparc/isa/formats/mem/util.isa | 26 ++
src/arch/sparc/mt.hh| 71 +
src/arch/sparc/registers.hh | 2 +
src/cpu/inorder/cpu.cc | 1 +
src/cpu/inorder/inorder_dyn_inst.cc | 19 +++
9 files changed, 134 insertions(+), 4 deletions(-)
diffs (274 lines):
diff -r 30daf1dd5c91 -r 77d12d8f7971 src/arch/sparc/isa/decoder.isa
--- a/src/arch/sparc/isa/decoder.isaWed Jun 08 11:58:09 2011 -0500
+++ b/src/arch/sparc/isa/decoder.isaThu Jun 09 01:34:06 2011 -0400
@@ -141,7 +141,7 @@
IntReg midVal;
R15 = midVal = (Pstate<3:> ? (PC)<31:0> : PC);
NNPC = midVal + disp;
-}});
+}},None, None, IsIndirectControl, IsCall);
0x2: decode OP3 {
format IntOp {
0x00: add({{Rd = Rs1.sdw + Rs2_or_imm13;}});
@@ -1005,7 +1005,7 @@
Rd = PC;
NNPC = target;
}
-}});
+}}, IsUncondControl, IsIndirectControl);
0x39: Branch::return({{
Addr target = Rs1 + Rs2_or_imm13;
if (fault == NoFault) {
@@ -1025,7 +1025,7 @@
Canrestore = Canrestore - 1;
}
}
-}});
+}}, IsUncondControl, IsIndirectControl, IsReturn);
0x3A: decode CC
{
0x0: Trap::tcci({{
diff -r 30daf1dd5c91 -r 77d12d8f7971 src/arch/sparc/isa/formats/branch.isa
--- a/src/arch/sparc/isa/formats/branch.isa Wed Jun 08 11:58:09 2011 -0500
+++ b/src/arch/sparc/isa/formats/branch.isa Thu Jun 09 01:34:06 2011 -0400
@@ -262,6 +262,9 @@
let {{
def doBranch(name, Name, base, cond,
code, annul_code, fail, annul_fail, opt_flags):
+if "IsIndirectControl" not in opt_flags:
+ opt_flags += ('IsDirectControl', )
+
iop = InstObjParams(name, Name, base,
{"code": code,
"fail": fail,
@@ -289,12 +292,14 @@
return (header_output, decoder_output, exec_output, decode_block)
def doCondBranch(name, Name, base, cond, code, opt_flags):
+opt_flags += ('IsCondControl', )
return doBranch(name, Name, base, cond, code, code,
'NNPC = NNPC; NPC = NPC;\n',
'NNPC = NPC + 8; NPC = NPC + 4;\n',
opt_flags)
def doUncondBranch(name, Name, base, code, annul_code, opt_flags):
+opt_flags += ('IsUncondControl', )
return doBranch(name, Name, base, "true", code, annul_code,
";", ";", opt_flags)
diff -r 30daf1dd5c91 -r 77d12d8f7971 src/arch/sparc/isa/formats/mem/basicmem.isa
--- a/src/arch/sparc/isa/formats/mem/basicmem.isa Wed Jun 08 11:58:09
2011 -0500
+++ b/src/arch/sparc/isa/formats/mem/basicmem.isa Thu Jun 09 01:34:06
2011 -0400
@@ -1,3 +1,5 @@
+// -*- mode:c++ -*-
+
// Copyright (c) 2006-2007 The Regents of The University of Michigan
// All rights reserved.
//
@@ -45,6 +47,8 @@
%(BasicExecDeclare)s
+%(EACompDeclare)s
+
%(InitiateAccDeclare)s
%(CompleteAccDeclare)s
@@ -69,6 +73,8 @@
exec_output = doDualSplitExecute(code, postacc_code, addrCalcReg,
addrCalcImm, execute, faultCode, name, name + "Imm",
Name, Name + "Imm", asi, opt_flags)
+exec_output += EACompExecute.subst(iop);
+exec_output += EACompExecute.subst(iop_imm);
return (header_output, decoder_output, exec_output, decode_block)
}};
diff -r 30daf1dd5c91 -r 77d12d8f7971 src/arch/sparc/isa/formats/mem/swap.isa
--- a/src/arch/sparc/isa/formats/mem/swap.isa Wed Jun 08 11:58:09 2011 -0500
+++ b/src/arch/sparc/isa/formats/mem/swap.isa Thu Jun 09 01:34:06 2011 -0400
@@ -163,7 +163,7 @@
"EA_trunc" : TruncateEA}
exec_output = doSplitExecute(execute, name, Name, mem_flags,
["IsStoreConditional"], microParams);
-return (header_output, decoder_output, exec_output, decode_block)
+return (
[gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpus/isa: add a != operator for pcstate Diffs - src/arch/generic/types.hh 77d12d8f7971 Diff: http://reviews.m5sim.org/r/738/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: sparc: init. cache state in TLB
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/739/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- sparc: init. cache state in TLB valgrind complains and its a potential source of instability, so go ahead and set it to 0 to start Diffs - src/arch/sparc/tlb.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/739/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/#review1303 --- I think you missed some (maybe just one) version of PC state defined in the ISAs themselves. ARM may be the only one, but you should double check to be sure. Also, for all these you could define them using ==, something like return !(*this == opc); - Gabe On 2011-06-08 22:46:05, Korey Sewell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/738/ > --- > > (Updated 2011-06-08 22:46:05) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > cpus/isa: add a != operator for pcstate > > > Diffs > - > > src/arch/generic/types.hh 77d12d8f7971 > > Diff: http://reviews.m5sim.org/r/738/diff > > > Testing > --- > > > Thanks, > > Korey > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: sparc: init. cache state in TLB
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/739/#review1304 --- Ship it! - Gabe On 2011-06-08 22:48:14, Korey Sewell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/739/ > --- > > (Updated 2011-06-08 22:48:14) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > sparc: init. cache state in TLB > valgrind complains and its a potential source of instability, so go ahead > and set it to 0 to start > > > Diffs > - > > src/arch/sparc/tlb.cc 77d12d8f7971 > > Diff: http://reviews.m5sim.org/r/739/diff > > > Testing > --- > > > Thanks, > > Korey > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: sparc: init. cache state in TLB
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/739/#review1305 --- Ship it! - Ali On 2011-06-08 22:48:14, Korey Sewell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/739/ > --- > > (Updated 2011-06-08 22:48:14) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > sparc: init. cache state in TLB > valgrind complains and its a potential source of instability, so go ahead > and set it to 0 to start > > > Diffs > - > > src/arch/sparc/tlb.cc 77d12d8f7971 > > Diff: http://reviews.m5sim.org/r/739/diff > > > Testing > --- > > > Thanks, > > Korey > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: alpha: make hwrei a control inst
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: make hwrei a control inst this always changes the PC and is basically an impromptu branch instruction. why not speculate on this instead of always be forced to mispredict/squash after the hwrei gets resolved? The InOrder model needs this marked as "isControl" so it knows to update the PC after the ALU executes it. If this isnt marked as control, then it's going to force the model to check the PC of every instruction at commit (what O3 does?), and that would be a wasteful check for a very high percentage of instructions. Diffs - src/arch/alpha/isa/decoder.isa 77d12d8f7971 Diff: http://reviews.m5sim.org/r/740/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: alpha: naming for dtb faults
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: naming for dtb faults Just "dfault" gets confusing while debugging. Why not differentiate whether it's an access violation or page fault Diffs - src/arch/alpha/faults.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/741/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
