* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
*
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
On Tue, Feb 17, 2009 at 9:59 PM, Korey Sewell ksew...@umich.edu wrote:
A few quick points from reading Steve's email:
- O wow, I just realized I got mixed up in saying that the O3
ExecContext is a thread context instead of a dyninst...my bad!...I
guess my point is that I would like to see
changeset e9f9c0f7e5f0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e9f9c0f7e5f0
description:
events: Make trace events happen at the right priority.
Also, while we're at it, remember that priorities are in the Event class
and add a disable method to
Thanks :-)
On Wed, Feb 18, 2009 at 11:37 AM, Nathan Binkert n...@binkert.org wrote:
changeset e9f9c0f7e5f0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e9f9c0f7e5f0
description:
events: Make trace events happen at the right priority.
Also, while we're at
Comments on this:
- Would we need a separate per-core object for core-wide ISA-specific
state? I'm guessing we might.
We might. There's no such thing right now that jumps to mind. I remember
there being some ambiguity with SPARC where some state might have been
for all threads in a core. I
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
Hi Steve/everyone,
right now, we have code in src/python/swig. I'm thinking that for the
swig stuff, we should distribute the .i files along with the code they
wrap. Mostly this means that swig code goes in sim. I'm thinking
about this because I was going to add a .i file or two and wanted to
A long time ago we talked about making some sort of hierarchy for
SimObjects so that they could mirror the namespaces in C++. That way I
wouldn't have to put IntelMP at the beginning of the name of all the
Intel MP table objects. In that case we'd want the python
package/directory
What a coincidence... I've never really looked at this code before about 4
hours ago. Brad and I were wondering where Stats::dump() gets called, and I
poked around and found src/python/swig/stats.i, and the first thing I thought
was shouldn't this really go in src/base/stats? I was going
10 matches
Mail list logo
