[m5-users] M5 v2.0 beta release available
We're happy to announce an official beta release of M5 2.0, including
all the new features described at our ISCA 2006 tutorial:
- A new execute-in-execute detailed out-of-order CPU model
- A new memory system
- More extensive python integration
- Preliminary syscall emulation support for MIPS and SPARC
We are still working out a few kinks, particularly in the area of MP
coherence support in the new memory system. We hope to have these
issues resolved soon, and will put out an official 2.0 release when
they are complete. In the meantime, we wanted to make the code base
available for those that don't need MP support, or who otherwise
would like a preview of the new 2.0 features.
For more information (including updated documentation and download
links) go to: http://www.m5sim.org
Also, please take a look at the new July/August issue of IEEE Micro,
which includes an article on M5.
Ali Saidi <saidi(a)umich.edu> writes:
We're happy to announce an official beta release of M5 2.0, including
all the new features described at our ISCA 2006 tutorial:
- A new execute-in-execute detailed out-of-order CPU model
- A new memory system
- More extensive python integration
- Preliminary syscall emulation support for MIPS and SPARC
Could you clarify the licensing status of the 2.0 release? The
distribution still has the encumbered directory and eio seems to be
compiled in from it. I'm still a bit uncomfortable about using M5 in
commercial context even if I would not use the eio features.
Below is a quick hack to add dup() to the syscall emu mode. For some
reason minigzip from zlib wants that.
While waiting for minigzip to compress rfc-index.txt I was thinking
whether anyone has considered accelerating the simulation with dynamic
compilation (QEMU-style)? LLVM looks like a nice C++ based compiler
framework so using it might be a good fit for M5 :-)
--- src/arch/alpha/linux/process.cc~ 2006-08-18 07:26:53.000000000 +0300
+++ src/arch/alpha/linux/process.cc 2006-08-27 19:47:56.000000000 +0300
@@ -162,8 +162,8 @@
/* 38 / SyscallDesc("osf_old_stat", unimplementedFunc),
/ 39 / SyscallDesc("setpgid", unimplementedFunc),
/ 40 */ SyscallDesc("osf_old_lstat", unimplementedFunc),
- /* 41 */ SyscallDesc("dup", unimplementedFunc),
- /* 41 / SyscallDesc("dup", dupFunc),
/ 42 / SyscallDesc("pipe", pipePseudoFunc),
/ 43 / SyscallDesc("osf_set_program_attributes", unimplementedFunc),
/ 44 */ SyscallDesc("osf_profil", unimplementedFunc),
--- src/sim/syscall_emul.hh~ 2006-08-18 07:26:53.000000000 +0300
+++ src/sim/syscall_emul.hh 2006-08-27 19:50:59.000000000 +0300
@@ -245,7 +249,11 @@
SyscallReturn fchownFunc(SyscallDesc *desc, int num,
Process *p, ThreadContext *tc);
+/// Target dup() handler.
+SyscallReturn dupFunc(SyscallDesc *desc, int num,
-
Process *process, ThreadContext *tc);
/// Target fnctl() handler.
SyscallReturn fcntlFunc(SyscallDesc *desc, int num,
Process *process, ThreadContext *tc);
--- src/sim/syscall_emul.cc~ 2006-08-18 07:26:55.000000000 +0300
+++ src/sim/syscall_emul.cc 2006-08-27 19:50:15.000000000 +0300
@@ -301,6 +319,19 @@
SyscallReturn
+dupFunc(SyscallDesc *desc, int num, Process *process, ThreadContext *tc)
+{
- int fd = process->sim_fd(tc->getSyscallArg(0));
- if (fd < 0)
- return -EBADF;
- int result = dup(fd);
- return (result == -1) ? -errno : process->alloc_fd(result);
+}
+SyscallReturn
fcntlFunc(SyscallDesc *desc, int num, Process *process,
ThreadContext *tc)
{
Antti P Miettinen wrote:
Ali Saidi <saidi(a)umich.edu> writes:
We're happy to announce an official beta release of M5 2.0, including
all the new features described at our ISCA 2006 tutorial:
- A new execute-in-execute detailed out-of-order CPU model
- A new memory system
- More extensive python integration
- Preliminary syscall emulation support for MIPS and SPARC
Could you clarify the licensing status of the 2.0 release? The
distribution still has the encumbered directory and eio seems to be
compiled in from it. I'm still a bit uncomfortable about using M5 in
commercial context even if I would not use the eio features.
Conceptually, things have not changed... all the stuff outside of the
'encumbered' directory is under a BSD-style license (ours or something
that appears to be compatible), and nothing in the 'encumbered'
directory is strictly required to build the simulator.
Practically, there are a couple of big changes. In previous releases,
even though you could build the simulator without the encumbered code,
both the functional memory object used in syscall emulation and the only
detailed timing CPU model were both in that tree, so you were pretty
much stuck with non-timing full system mode if you avoided the
encumbered tree. None of the new code we've added is encumbered, so the
new detailed out-of-order model and the new memory system are under our
license, so now you can do almost anything w/o the encumbered code. In
fact the old encumbered CPU model doesn't work with the new memory
system (though we have plans to do a port for legacy reasons) and the
old encumbered functional memory object is now totally irrelevant, which
is why the EIO code is the only piece that's still compiled in by
default. You should be able to just remove those lines from
src/SConstruct and m5 will build as normal. All you'll lose is EIO
trace support (so you'll fail the one or two regression tests that rely
on that).
Would it help if we repackaged our releases so that the base package
didn't include the encumbered code, and you could download it separately
if you needed it?
Below is a quick hack to add dup() to the syscall emu mode. For some
reason minigzip from zlib wants that.
Thanks... we'll get that in our tree so it'll be in the next release.
Steve
Steve Reinhardt <stever(a)eecs.umich.edu> writes:
Would it help if we repackaged our releases so that the base package
didn't include the encumbered code, and you could download it
separately if you needed it?
That would be perfect as then there really would be no room for
speculation. I was thinking something like this but did not dare
suggest it :-)
Antti P Miettinen wrote:
While waiting for minigzip to compress rfc-index.txt I was thinking
whether anyone has considered accelerating the simulation with dynamic
compilation (QEMU-style)? LLVM looks like a nice C++ based compiler
framework so using it might be a good fit for M5 :-)
That sounds cool... I've thought about dynamic compilation, but shied
away from it due to portability issues (not to mention total lack of
time). LLVM might be a good solution to that.
A simpler (though non-trivial) and likely effective optimization that
I've been thinking about for a couple of years now is to cache decoded
pages of StaticInst pointers. Right now every time a CPU fetches an
instruction, we fetch the binary representation from simulated memory,
then look it up in a hash table to get a pointer to the appropriate
StaticInst object. I'd like to keep an additional page of StaticInst
pointers for each page that contains instructions, and then instruction
fetches can grab the pointers right off there without the hash table
lookup (which is one of the most time-consuming functions if you're
doing simple functional simulation).
My current thought would be to associate these decoded instruction pages
with TLB entries; then after we run the ifetch through the ITLB we could
just take the PC's page offset and use that to grab the StaticInst
pointer. Leveraging the TLB lookup automatically takes care of handling
the case where the PC moves to a different physical page (whether due to
a jump or falling off the end). Another issue is invalidating the
cached page when the page is written to (probably not necessary in SE
mode, but definitely needed in FS).
Thought I'd throw this out there in case someone has the free time to
work on it...
Steve