Re: [gem5-dev] registerThreadContext

2011-05-31 Thread Gabe Black
On 05/31/11 22:43, Steve Reinhardt wrote:
> On Wed, May 25, 2011 at 10:57 AM, nathan binkert  wrote:
>> I see a few options for solving this problem:
>> 1) Separate out the contextId allocation from registerThreadContext so
>> things like DMA controllers and memtesters can get allocated a
>> contextID.
>> 2) Create a base class for ThreadContext that is far simpler than the
>> current thread context and use that when registering.
>> 3) Figure out contextID not by registration, but instead by doing a
>> traversal of the memory system.  This would require that we have some
>> sort of indication differentiating memory objects that can generate
>> requests and thus require a contextID and memory objects that can't
>> (caches, dram, pio devices, etc.).  We add a constructor parameter to
>> the MemObject base class.
>> 4) Add a separate registration function for non Thread Contexts.
> While #3 sounds nice, it's a relatively big change, and would have to
> be done in a way that works both for the m5 classic memory system and
> for Ruby, and ideally is robust and predictable in assigning
> contextIDs in the face of minor configuration changes.  My guess is
> that it will end up being harder than it sounds... maybe Korey can
> speak up if his experience indicates otherwise.
>
> The others seem more reasonable, but possibly still overkill.
>
> The idea I had, that's kind of a hack but combines #2 and #4 in a
> degenerate sort of way, would be to allow non-ThreadContext objects to
> call registerThreadContext, but they would pass in NULL for the
> ThreadContext pointer.  This would allow something like a DMA device
> or the memtester to reserve or allocate a context ID without being a
> ThreadContext, but without creating an additional base class.  The
> only down side I see is that error tracking would be harder; if two
> non-ThreadContexts tried to claim the same ID, the System would not
> have a pointer to be able to identify the first one.  Basically that's
> the only case I can see where it would be useful for the System object
> to hold on to some kind of pointer for something that's not an actual
> ThreadContext.  Of course, the current ThreadContext pointers don't
> have any real debug info either, so even now you just get "Cannot have
> two CPUs with the same id (%d)\n" when you try to reuse a context ID,
> so apparently it hasn't been a big problem.
>
> If we cared about providing good error messages, we could extend
> registerThreadContext to take both a SimObject* and a ThreadContext*
> and track both of these, but make the latter optional.  This would
> provide better error messages for everyone (though again, this hasn't
> been a problem that I've seen).  registerThreadContext is only called
> from one place (BaseCPU::registerThreadContexts()) so it wouldn't be
> hard to change that.
>
> Just some ideas...
>
> Steve
> ___
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev

One drawback I see with this sort of approach is that you have to be
careful if you want to loop over all registered contexts and do
something with their thread contexts. You'd have to be careful to check
which ones were NULL, and if that's uncommon it might be easy to forget
to do.

Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] registerThreadContext

2011-05-31 Thread Steve Reinhardt
On Wed, May 25, 2011 at 10:57 AM, nathan binkert  wrote:
>
> I see a few options for solving this problem:
> 1) Separate out the contextId allocation from registerThreadContext so
> things like DMA controllers and memtesters can get allocated a
> contextID.
> 2) Create a base class for ThreadContext that is far simpler than the
> current thread context and use that when registering.
> 3) Figure out contextID not by registration, but instead by doing a
> traversal of the memory system.  This would require that we have some
> sort of indication differentiating memory objects that can generate
> requests and thus require a contextID and memory objects that can't
> (caches, dram, pio devices, etc.).  We add a constructor parameter to
> the MemObject base class.
> 4) Add a separate registration function for non Thread Contexts.

While #3 sounds nice, it's a relatively big change, and would have to
be done in a way that works both for the m5 classic memory system and
for Ruby, and ideally is robust and predictable in assigning
contextIDs in the face of minor configuration changes.  My guess is
that it will end up being harder than it sounds... maybe Korey can
speak up if his experience indicates otherwise.

The others seem more reasonable, but possibly still overkill.

The idea I had, that's kind of a hack but combines #2 and #4 in a
degenerate sort of way, would be to allow non-ThreadContext objects to
call registerThreadContext, but they would pass in NULL for the
ThreadContext pointer.  This would allow something like a DMA device
or the memtester to reserve or allocate a context ID without being a
ThreadContext, but without creating an additional base class.  The
only down side I see is that error tracking would be harder; if two
non-ThreadContexts tried to claim the same ID, the System would not
have a pointer to be able to identify the first one.  Basically that's
the only case I can see where it would be useful for the System object
to hold on to some kind of pointer for something that's not an actual
ThreadContext.  Of course, the current ThreadContext pointers don't
have any real debug info either, so even now you just get "Cannot have
two CPUs with the same id (%d)\n" when you try to reuse a context ID,
so apparently it hasn't been a big problem.

If we cared about providing good error messages, we could extend
registerThreadContext to take both a SimObject* and a ThreadContext*
and track both of these, but make the latter optional.  This would
provide better error messages for everyone (though again, this hasn't
been a problem that I've seen).  registerThreadContext is only called
from one place (BaseCPU::registerThreadContexts()) so it wouldn't be
hard to change that.

Just some ideas...

Steve
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Functional Memory Accesses in Ruby

2011-05-31 Thread Nilay Vaish

On Sat, 28 May 2011, Nilay Vaish wrote:


Hi Brad

I am trying to complete the patch on functional accesses in Ruby. I came 
across this problem while testing the patch for higher number of processors. 
I am working with MESI CMP directory protocol right now. So I will describe 
the problem in its context.


Assume we are trying to functionally write some thing to block A. It is in 
state S_I in the L2 cache. When a block moves to state S_I from state SS, 
then the cache block in the cache is deallocated. Therefore, when viewed from 
the CacheMemory's perpespective, since the cache does not have block A, 
therefore, the L2 cache is of no consequence for this access. But the 
controller has a TBE for this block. And this TBE will have this block with 
AccessPermission:Busy. Also, there are L1 caches in the system that hold this 
block in S state.


Now, as per the current condition for write functional accesses,

if((num_busy == 0 && num_ro > 0) || num_rw == 1)

this access would go ahead as num_busy would evaluate to 0 and num_ro would 
evaluate to some value greater than 0. But clearly we do not want this access 
to be performed since that state S_I is a busy state and no other cache holds 
the block in a read-write state.


It seems to me that the controller should supply the function for deciding 
the access permissions, since it is possible that one the TBE holds the 
block.


--
Nilay



Brad, I went over the discussion that we had this morning. I think the 
getState() function cannot be used for extracting access permissions. This 
is because the getState() function needs pouinters to transaction buffer 
and cache entries, apart from the address.


I think we should let the Controller provide a function for getting the 
access permissions. This function would be a virtual function declared in 
the AbstractController class, but would not be pure. The 
AbstractController implementation of the function would always return 
busy, so that functional accesses are not enabled at all for protocols 
that do not provide such a function.


--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in web-graphics: Resize topology figure

2011-05-31 Thread Tushar Krishna
changeset c1a85b596072 in /z/repo/web-graphics
details: web-graphics?cmd=changeset;node=c1a85b596072
description:
Resize topology figure

diffstat:

 ruby/figures/Topology_overview.jpg |0 
 1 files changed, 0 insertions(+), 0 deletions(-)

diffs (2 lines):

diff -r 8b47475cd2b3 -r c1a85b596072 ruby/figures/Topology_overview.jpg
Binary file ruby/figures/Topology_overview.jpg has changed
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] changeset in web-graphics: network: updated topology figure

2011-05-31 Thread Tushar Krishna
changeset 8b47475cd2b3 in /z/repo/web-graphics
details: web-graphics?cmd=changeset;node=8b47475cd2b3
description:
network: updated topology figure

diffstat:

 ruby/figures/Topology_overview.jpg |0 
 1 files changed, 0 insertions(+), 0 deletions(-)

diffs (2 lines):

diff -r 1f62f3ea6275 -r 8b47475cd2b3 ruby/figures/Topology_overview.jpg
Binary file ruby/figures/Topology_overview.jpg has changed
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Ali Saidi
On Tue, 31 May 2011 14:46:37 -0400, Tushar Krishna 
 wrote:

Thanks Ali.
This is the repo right?
h...@m5sim.org/web-graphics


Yes


And how do I point to the images in the repo from the wiki?


http://www.gem5.org/graphics

Ali

___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Tushar Krishna

Thanks Ali.
This is the repo right?
h...@m5sim.org/web-graphics

And how do I point to the images in the repo from the wiki?

Thanks,
Tushar


On 5/31/2011 2:13 PM, Ali Saidi wrote:

Upload graphics using the repository not the wiki interface.

Thanks,
Ali


On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna 
 wrote:

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


Re: [gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Ali Saidi

Upload graphics using the repository not the wiki interface.

Thanks,
Ali


On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna 
 wrote:

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] Unable to upload figures to wiki

2011-05-31 Thread Tushar Krishna

Hi Nate,
I am unable to upload new figures to the wiki.

I get this upload warning:
The upload directory (public) is not writable by the webserver.

Does this have something to do with permissions?

Thanks,
Tushar
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev


[gem5-dev] Cron /z/m5/regression/do-regression quick

2011-05-31 Thread Cron Daemon
scons: `build/ALPHA_SE/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.debug' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.debug' is up to date.
scons: `build/ALPHA_FS/m5.debug' is up to date.
scons: `build/MIPS_SE/m5.debug' is up to date.
scons: `build/POWER_SE/m5.debug' is up to date.
scons: `build/SPARC_SE/m5.debug' is up to date.
scons: `build/SPARC_FS/m5.debug' is up to date.
scons: `build/X86_SE/m5.debug' is up to date.
scons: `build/X86_FS/m5.debug' is up to date.
scons: `build/ARM_SE/m5.debug' is up to date.
scons: `build/ARM_FS/m5.debug' is up to date.
scons: `build/ALPHA_SE/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.fast' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.fast' is up to date.
scons: `build/ALPHA_FS/m5.fast' is up to date.
scons: `build/MIPS_SE/m5.fast' is up to date.
scons: `build/POWER_SE/m5.fast' is up to date.
scons: `build/SPARC_SE/m5.fast' is up to date.
scons: `build/SPARC_FS/m5.fast' is up to date.
scons: `build/X86_SE/m5.fast' is up to date.
scons: `build/X86_FS/m5.fast' is up to date.
scons: `build/ARM_SE/m5.fast' is up to date.
scons: `build/ARM_FS/m5.fast' is up to date.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed.
* 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/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-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/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-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/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-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/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-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_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_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/50.memtest/alpha/linux/memtest-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_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-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/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
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/linu

Re: [gem5-dev] Review Request: ISA parser: Simplify operand type handling.

2011-05-31 Thread Gabe Black
On 05/30/11 21:57, Steve Reinhardt wrote:
> On Mon, May 30, 2011 at 1:33 PM, Gabe Black  wrote:
>> On 05/30/11 09:47, Steve Reinhardt wrote:
>>> Anyway, it seems very odd to have to say "(int8_t)Mem.ub" when we already 
>>> have a ".sb" operand type defined as "int8_t".  It seems like a weird 
>>> hidden restriction to say that there are operand types you can declare but 
>>> can't use on memory, and that you're pushing a somewhat arbitrary internal 
>>> implementation decision up to the level of language visibility, which is 
>>> going the wrong direction.  I'm not sure what the right solution is, but 
>>> even if it's the brute force one of creating a bunch more read/write 
>>> function templates in the CPU implementations, I think that's preferable.
>> [...]
>>
>> The unsigned thing is sort of a weird gotcha. I'd like to avoid adding a
>> lot of bulk to the CPU models since they're already fairly chunky and it
>> makes them harder to reason about looking through the code, but it would
>> be great to straighten this out. One possibility might be the technique
>> I used with the endianness changing functions in src/sim/byteswap.hh.
>> Things are built up in layers there:
>> [...]
> I think some kind of additional set of template instantiations should
> do it.  I just noticed that we already have:
>
> template<>
> Fault
> AtomicSimpleCPU::read(Addr addr, int32_t &data, unsigned flags)
> {
> return read(addr, (uint32_t&)data, flags);
> }
>
> template<>
> Fault
> AtomicSimpleCPU::write(int32_t data, Addr addr, unsigned flags, uint64_t *res)
> {
> return write((uint32_t)data, addr, flags, res);
> }
>
> .. and similar for TimingSimpleCPU; do we just need to extend these to
> int8_t and int16_t, and maybe add similar sets in
> base_dynamic_inst.hh?
>
> Steve
> ___
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev

Oh yeah, I guess we're already doing something like that, and that glob
of code was just instantiating different versions of the function. Could
we reduce the amount of text by moving it into the header? There isn't a
lot of actual information there in all that text, and we're talking
about doubling it. I don't have a better idea, though.

Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev