[m5-dev] changeset in m5: Update stats for new prefetching fixes.
changeset 7202be891bb4 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=7202be891bb4 description: Update stats for new prefetching fixes. Prefetching is not enabled in any of our regressions, so no significant stat values have changed, but zero-valued prefetch stats no longer show up when prefetching is disabled so there are noticable changes in the reference stat files anyway. diffstat: 261 files changed, 2357 insertions(+), 2445 deletions(-) tests/long/00.gzip/ref/alpha/tru64/o3-timing/config.ini | 12 tests/long/00.gzip/ref/alpha/tru64/o3-timing/simerr |2 tests/long/00.gzip/ref/alpha/tru64/o3-timing/simout | 10 tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt | 35 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/config.ini |3 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simerr |2 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simout | 10 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/stats.txt |8 tests/long/00.gzip/ref/alpha/tru64/simple-timing/config.ini | 12 tests/long/00.gzip/ref/alpha/tru64/simple-timing/simerr |2 tests/long/00.gzip/ref/alpha/tru64/simple-timing/simout | 10 tests/long/00.gzip/ref/alpha/tru64/simple-timing/stats.txt | 35 tests/long/00.gzip/ref/sparc/linux/o3-timing/config.ini | 12 tests/long/00.gzip/ref/sparc/linux/o3-timing/simerr |3 tests/long/00.gzip/ref/sparc/linux/o3-timing/simout |9 tests/long/00.gzip/ref/sparc/linux/o3-timing/stats.txt | 35 tests/long/00.gzip/ref/sparc/linux/simple-atomic/config.ini |3 tests/long/00.gzip/ref/sparc/linux/simple-atomic/simerr |3 tests/long/00.gzip/ref/sparc/linux/simple-atomic/simout |9 tests/long/00.gzip/ref/sparc/linux/simple-atomic/stats.txt |8 tests/long/00.gzip/ref/sparc/linux/simple-timing/config.ini | 12 tests/long/00.gzip/ref/sparc/linux/simple-timing/simerr |3 tests/long/00.gzip/ref/sparc/linux/simple-timing/simout |9 tests/long/00.gzip/ref/sparc/linux/simple-timing/stats.txt | 35 tests/long/00.gzip/ref/x86/linux/simple-atomic/config.ini |5 tests/long/00.gzip/ref/x86/linux/simple-atomic/simerr | 10 tests/long/00.gzip/ref/x86/linux/simple-atomic/simout | 12 tests/long/00.gzip/ref/x86/linux/simple-atomic/stats.txt |8 tests/long/00.gzip/ref/x86/linux/simple-timing/config.ini | 14 tests/long/00.gzip/ref/x86/linux/simple-timing/simerr | 10 tests/long/00.gzip/ref/x86/linux/simple-timing/simout | 12 tests/long/00.gzip/ref/x86/linux/simple-timing/stats.txt | 35 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/config.ini | 34 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simerr |6 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simout | 10 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt | 62 - tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini | 27 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/simerr |5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/simout | 10 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt | 44 tests/long/10.mcf/ref/sparc/linux/simple-atomic/config.ini |3 tests/long/10.mcf/ref/sparc/linux/simple-atomic/simerr |3 tests/long/10.mcf/ref/sparc/linux/simple-atomic/simout |9 tests/long/10.mcf/ref/sparc/linux/simple-atomic/stats.txt |8 tests/long/10.mcf/ref/sparc/linux/simple-timing/config.ini | 12 tests/long/10.mcf/ref/sparc/linux/simple-timing/simerr |3 tests/long/10.mcf/ref/sparc/linux/simple-timing/simout |9
[m5-dev] Undelivered Mail Returned to Sender
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 your own text from the attached returned message. The mail system dan...@yandex.ru: host mx2.yandex.ru[93.158.134.89] said: 550 5.1.1 dan...@yandex.ru user unknown (in reply to RCPT TO command) Reporting-MTA: dns; daystrom.m5sim.org X-Postfix-Queue-ID: 92D5D1581C3 X-Postfix-Sender: rfc822; m5-dev@m5sim.org Arrival-Date: Mon, 16 Feb 2009 13:25:14 -0500 (EST) Final-Recipient: rfc822; Dan1oo@yandex.ru Action: failed Status: 5.1.1 Remote-MTA: dns; mx2.yandex.ru Diagnostic-Code: smtp; 550 5.1.1 Dan1oo@yandex.ru user unknown ---BeginMessage--- This address has been used to register a Flyspray account. If you were not expecting this message, please ignore and delete it. Go to the following URL to complete your registration: http://www.m5sim.org/flyspray/index.php?do=registermagic=02972fe39804e91806c0f91a48f47ffa Your confirmation code is: 7aBRpEVlz8OyQ ---End Message--- ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] 32 bit vs. 64 bit regressions
I agree that having both optimized and unoptimized binaries for at least some workloads is useful for regressions, but I'm not convinced it's a huge loss to require different names for them... you'd get some duplication in the input files but that's about it. However, there are enough things that need to be fixed about the regression system that we might as well add this capability in while we're fixing everything else. I think the 32- vs 64-bit regression should already be taken care of as long as those appear as independent operating systems (or even ISAs)... I'm guessing your problem before was that you weren't making that distinction at the top level. We should also get some regressions that use prefetching; it's unlikely the prefetching code would have gotten so broken if we had. I think the current structure is capable of handling this by creating a new platform (e.g., 'simple-timing-prefetch' in addition to 'simple-timing'), but there may be a better way to support variations like this if we revamp the whole system. Steve On Mon, Feb 16, 2009 at 1:54 AM, Gabe Black gbl...@eecs.umich.edu wrote: I have a 32 bit hello world working, and thinking about making it part of the regressions reminded me of when I was doing something similar for SPARC. Back then I didn't find a good way for 32 bit and 64 bit benchmarks/binaries to exist in the regression system at the same time since they're always expected to be in the same directory with the same name. It would be nice to be able to also have, for instance, 32 bit versions of hello world compiled with and without optimizations. I've found the optimized binaries are non trivially harder to run correctly, but they may not cover all the same cases as the unoptimized ones. If we're doing some sort of fancy regressions overhaul in the future, it would be nice if this sort of thing could be accommodated better. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Scons 0.98 build problems...
Hey all,
I am currently unable to build any CPU Model successfully after the scons
update...0
Other people seem to be doing just fine, so am I missing something?
My error message has something to do with generating a defines.py file:
makeDefinesPyFile([build/ALPHA_SE/python/m5/defines.py], [{'ALPHA_TLASER':
False, 'FAST_ALLOC_STATS': False, 'FAST_ALLOC_DEBUG': False, 'USE_CHECKER':
False, 'SS_COMPATIBLE_FP': True, 'NO_FAST_ALLOC': False, 'USE_FENV': True,
'TARGET_ISA': 'alpha', 'FULL_SYSTEM': False, 'USE_MYSQL': False}, extension
'hgext/mq' overrides commands: qheader qnew ^qpop qrestore qapplied qguard
qclone ^strip qgoto qprev qunapplied ^qrefresh qtop ^qdiff qseries
qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport qselect ^qpush ^qinit
qrename|qmv qsave\nextension 'patchbomb' overrides commands: email\nTag
inorder-thread-context-updates.diff overrides mq patch of the same name\nTag
qtip overrides mq patch of the same name\nTag qbase overrides mq patch of
the same name\nTag qparent overrides mq patch of the same name\nec076c266464
5875 default qtip tip inorder-thread-context-updates.diff qbase])
objectifyPyFile([build/ALPHA_SE/python/m5/defines.py.s],
[build/ALPHA_SE/python/m5/defines.py])
scons: *** [build/ALPHA_SE/python/m5/defines.py.s] Exception
Traceback (most recent call last):
File /usr/lib/scons/SCons/Taskmaster.py, line 222, in execute
self.targets[0].build()
File /usr/lib/scons/SCons/Node/__init__.py, line 372, in build
apply(self.get_executor(), (self,), kw)
File /usr/lib/scons/SCons/Executor.py, line 145, in __call__
return self.do_execute(target, kw)
File /usr/lib/scons/SCons/Executor.py, line 131, in do_execute
status = apply(act, (self.targets, self.get_sources(), env), kw)
File /usr/lib/scons/SCons/Action.py, line 468, in __call__
stat = self.execute(target, source, env)
File /usr/lib/scons/SCons/Action.py, line 846, in execute
result = self.execfunction(target=target, source=rsources, env=env)
File /home/ksewell/m5-fresh/build/ALPHA_SE/SConscript, line 843, in
objectifyPyFile
compiled = compile(src, pysource.debugname, 'exec')
File /home/ksewell/m5-fresh/build/ALPHA_SE/python/m5/defines.py, line 2
hgRev = 'extension 'hgext/mq' overrides commands: qheader qnew ^qpop
qrestore qapplied qguard qclone ^strip qgoto qprev qunapplied ^qrefresh qtop
^qdiff qseries qcommit|qci qfold qnext qdelete|qremove|qrm ^qimport qselect
^qpush ^qinit qrename|qmv qsave
--
--
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science Engineering
University of Michigan
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: sycalls: implement mremap() and add DATA flag f...
changeset 9fe574944f31 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9fe574944f31
description:
sycalls: implement mremap() and add DATA flag for getrlimit(). mremap
has been tested on Alpha, compiles for the rest but not tested. I don't see why
it wouldn't work though.
diffstat:
11 files changed, 121 insertions(+), 6 deletions(-)
src/arch/alpha/linux/process.cc |2 -
src/arch/alpha/pagetable.hh |7
src/arch/mips/linux/process.cc |2 -
src/arch/mips/tlb.hh |3 ++
src/arch/sparc/linux/syscalls.cc |4 +-
src/arch/sparc/pagetable.hh |6
src/arch/x86/linux/syscalls.cc |2 -
src/arch/x86/pagetable.hh|6
src/mem/page_table.cc| 38 ++
src/mem/page_table.hh|2 +
src/sim/syscall_emul.hh | 55 +-
diffs (263 lines):
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/alpha/linux/process.cc
--- a/src/arch/alpha/linux/process.cc Mon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/alpha/linux/process.cc Mon Feb 16 17:47:39 2009 -0500
@@ -463,7 +463,7 @@
/* 338 */ SyscallDesc(afs_syscall, unimplementedFunc),
/* 339 */ SyscallDesc(uname, unameFunc),
/* 340 */ SyscallDesc(nanosleep, unimplementedFunc),
-/* 341 */ SyscallDesc(mremap, unimplementedFunc),
+/* 341 */ SyscallDesc(mremap, mremapFuncAlphaLinux),
/* 342 */ SyscallDesc(nfsservctl, unimplementedFunc),
/* 343 */ SyscallDesc(setresuid, unimplementedFunc),
/* 344 */ SyscallDesc(getresuid, unimplementedFunc),
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/alpha/pagetable.hh
--- a/src/arch/alpha/pagetable.hh Mon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/alpha/pagetable.hh Mon Feb 16 17:47:39 2009 -0500
@@ -123,6 +123,13 @@
TlbEntry()
{}
+void
+updateVaddr(Addr new_vaddr)
+{
+VAddr vaddr(new_vaddr);
+tag = vaddr.vpn();
+}
+
Addr
pageStart()
{
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/mips/linux/process.cc
--- a/src/arch/mips/linux/process.ccMon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/mips/linux/process.ccMon Feb 16 17:47:39 2009 -0500
@@ -288,7 +288,7 @@
/* 164 */ SyscallDesc(sched_get_priority_min, unimplementedFunc),
/* 165 */ SyscallDesc(sched_rr_get_interval, unimplementedFunc),
/* 166 */ SyscallDesc(nanosleep, unimplementedFunc),
-/* 167 */ SyscallDesc(mremap, unimplementedFunc),
+/* 167 */ SyscallDesc(mremap, mremapFuncMipsLinux),
/* 168 */ SyscallDesc(accept, unimplementedFunc),
/* 169 */ SyscallDesc(bind, unimplementedFunc),
/* 170 */ SyscallDesc(connect, unimplementedFunc),
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/mips/tlb.hh
--- a/src/arch/mips/tlb.hh Mon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/mips/tlb.hh Mon Feb 16 17:47:39 2009 -0500
@@ -68,6 +68,9 @@
return _pageStart;
}
+void
+updateVaddr(Addr new_vaddr) {}
+
void serialize(std::ostream os)
{
SERIALIZE_SCALAR(_pageStart);
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/sparc/linux/syscalls.cc
--- a/src/arch/sparc/linux/syscalls.cc Mon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/sparc/linux/syscalls.cc Mon Feb 16 17:47:39 2009 -0500
@@ -339,7 +339,7 @@
/* 247 */ SyscallDesc(sched_get_priority_min, unimplementedFunc), //32
bit
/* 248 */ SyscallDesc(sched_rr_get_interval, unimplementedFunc), //32 bit
/* 249 */ SyscallDesc(nanosleep, unimplementedFunc),
-/* 250 */ SyscallDesc(mremap, unimplementedFunc), //32 bit
+/* 250 */ SyscallDesc(mremap, mremapFuncSparc32Linux), //32 bit
/* 251 */ SyscallDesc(_sysctl, unimplementedFunc), //32 bit
/* 252 */ SyscallDesc(getsid, unimplementedFunc), //32 bit
/* 253 */ SyscallDesc(fdatasync, unimplementedFunc),
@@ -642,7 +642,7 @@
/* 247 */ SyscallDesc(sched_get_priority_min, unimplementedFunc),
/* 248 */ SyscallDesc(sched_rr_get_interval, unimplementedFunc),
/* 249 */ SyscallDesc(nanosleep, unimplementedFunc),
-/* 250 */ SyscallDesc(mremap, unimplementedFunc),
+/* 250 */ SyscallDesc(mremap, mremapFuncSparcLinux),
/* 251 */ SyscallDesc(_sysctl, unimplementedFunc),
/* 252 */ SyscallDesc(getsid, unimplementedFunc),
/* 253 */ SyscallDesc(fdatasync, unimplementedFunc),
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/sparc/pagetable.hh
--- a/src/arch/sparc/pagetable.hh Mon Feb 16 12:09:45 2009 -0500
+++ b/src/arch/sparc/pagetable.hh Mon Feb 16 17:47:39 2009 -0500
@@ -266,6 +266,12 @@
return pte.paddr();
}
+void
+updateVaddr(Addr new_vaddr)
+{
+range.va = new_vaddr;
+}
+
void serialize(std::ostream os);
void unserialize(Checkpoint *cp, const std::string section);
};
diff -r 7202be891bb4 -r 9fe574944f31 src/arch/x86/linux/syscalls.cc
--- a/src/arch/x86/linux/syscalls.ccMon Feb 16 12:09:45 2009 -0500
+++
[m5-dev] push - no email
hey guys, i just pushed something and haven't gotten an email notification - has anyone else? lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] push - no email
I got one for your recent push unless there was more than one. Sometimes mine get caught in the spam filter so you might want to check in your junk folder. Gabe Lisa Hsu wrote: hey guys, i just pushed something and haven't gotten an email notification - has anyone else? lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] push - no email
You're right, thanks Gabe. That's the first time (that I know of) that one of my own emails ended up in my own spam box. Heh. Lisa On Mon, Feb 16, 2009 at 6:28 PM, Gabe Black gbl...@eecs.umich.edu wrote: I got one for your recent push unless there was more than one. Sometimes mine get caught in the spam filter so you might want to check in your junk folder. Gabe Lisa Hsu wrote: hey guys, i just pushed something and haven't gotten an email notification - has anyone else? lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] vsyscall page and license issues
In x86 there are at least three different ways to call a system call, int $0x80, sysenter, and syscall. In 64 bit mode I think syscall is pretty much guaranteed to be there so glibc uses it directly, or at least that's been my experience. For 32 bit x86, though, sysenter, the preferred of the two remaining instructions, is not necessarily present or enabled. What Linux does to handle this situation is that there's a vsyscall page which the kernel defines and which is mapped into the user level process at an address the kernel provides through an auxiliary vector on the initial stack frame. When it wants to do a system call, it jumps to the right location on the vsyscall page and the right instruction is there. Otherwise, system calls happen through the relatively slow int $0x80 interface. This is generally fine and it's not hard to put that page in place and put something useful on it, but in order to exactly match native execution in M5 I need to put the exact same instructions on my vsyscall page as appears in Linux. I don't know how this all works as far as licensing goes. Do we have to use GPL if I copy the bytes that implement a portion of that page into M5 for compatibility? How many instructions are we talking about? If it's only a handful and there is only one way you can do things, I think it should be ok. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well. If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... It turns out that I had forgotten about the relationship between ThreadContext, ExecContext, and registers. I had a chance to discuss this with Steve and Gabe today and Gabe has agreed to write something up to describe how to solve this problem cleanly across the CPU models. I think that part of the problem is that the register file shouldn't really be defined in the ISA, and the ExecContext needs a consistent way for accessing registers. We'll probably end up with new functions for accessing registers from other threads instead of modifying the existing ones. Hopefully one of the things that will fall out of this work is consistent, working thread support across the various CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] vsyscall page and license issues
nathan binkert wrote: In x86 there are at least three different ways to call a system call, int $0x80, sysenter, and syscall. In 64 bit mode I think syscall is pretty much guaranteed to be there so glibc uses it directly, or at least that's been my experience. For 32 bit x86, though, sysenter, the preferred of the two remaining instructions, is not necessarily present or enabled. What Linux does to handle this situation is that there's a vsyscall page which the kernel defines and which is mapped into the user level process at an address the kernel provides through an auxiliary vector on the initial stack frame. When it wants to do a system call, it jumps to the right location on the vsyscall page and the right instruction is there. Otherwise, system calls happen through the relatively slow int $0x80 interface. This is generally fine and it's not hard to put that page in place and put something useful on it, but in order to exactly match native execution in M5 I need to put the exact same instructions on my vsyscall page as appears in Linux. I don't know how this all works as far as licensing goes. Do we have to use GPL if I copy the bytes that implement a portion of that page into M5 for compatibility? How many instructions are we talking about? If it's only a handful and there is only one way you can do things, I think it should be ok. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev It's only a few instructions to push three registers on the stack, use the appropriate instruction, pop those three, and return. All together it's 11 bytes. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I'm not sure I all the way understand why the register file shouldnt be defined in the ISA... I could see maybe there being one standard integer and floating point register file thats totally generic however, the system/miscellaneous registers are pretty ISA dependent so those register probably need to be defined in some custom manner. Anyway, I was just about to rearrange everything so that all accesses to registers use the ThreadContext instead of directly going through the CPU (for the InOrder model at least). I'll assume that I should hold off on that for now? On Mon, Feb 16, 2009 at 11:17 PM, nathan binkert n...@binkert.org wrote: If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well. If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... It turns out that I had forgotten about the relationship between ThreadContext, ExecContext, and registers. I had a chance to discuss this with Steve and Gabe today and Gabe has agreed to write something up to describe how to solve this problem cleanly across the CPU models. I think that part of the problem is that the register file shouldn't really be defined in the ISA, and the ExecContext needs a consistent way for accessing registers. We'll probably end up with new functions for accessing registers from other threads instead of modifying the existing ones. Hopefully one of the things that will fall out of this work is consistent, working thread support across the various CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] vsyscall page and license issues
It's only a few instructions to push three registers on the stack, use the appropriate instruction, pop those three, and return. All together it's 11 bytes. I don't think one can claim copyright on 11 bytes. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: InOrder: Import new inorder CPU model from MIPS.
I'm not sure I all the way understand why the register file shouldnt be defined in the ISA... I could see maybe there being one standard integer and floating point register file thats totally generic however, the system/miscellaneous registers are pretty ISA dependent so those register probably need to be defined in some custom manner. Anyway, I was just about to rearrange everything so that all accesses to registers use the ThreadContext instead of directly going through the CPU (for the InOrder model at least). I'll assume that I should hold off on that for now? I think at this point, we need more discussion and less action. If you think you know how to make the ThreadContext stuff work right, please write up a description of how it will work. I think I was mistaken in saying that we could do it that way. Please also make sure that whatever you propose is consistent across the CPU models. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
