Re: [m5-dev] Unprintable characters in license files
On Mar 17, 2008, at 1:52 PM, Korey Sewell wrote: looks like the characters it doesnt like are just quotation marks... so MIPS instead of ??MIPS??... Should be some find/replace work to fix this up... How does the X copyright holders thing work? We need to figure that out. Nate? Steve? How can we get to a place where we can have (c) 200X University of Michigan (c) 200X MIPS (c) 200X FSU instead of 100 lines of license? Ali On Tue, Mar 11, 2008 at 1:15 AM, Ali Saidi [EMAIL PROTECTED] wrote: Also, we really need to be able to just append the X copyright holders to the same bsd license blurb if everyone is using the same thing. 100 lines of license text and 25 lines of actual code is ridiculous. What needs to be done to do that? Ali src/base/loader/hex_file.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta_cchip.hh: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta_cchip.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta.hh: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/arch/mips/pra_constants.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/utility.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/linux/linux.cc: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/linux/linux.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/linux/process.cc: * the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/mips_core_specific.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/mips_core_specific.cc: * the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/utility.cc: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/MipsCPU.py:# the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/faults.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/system.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/isa/includes.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/operands.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/mem.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/noop.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/int.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/mt.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/control.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/util.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/trap.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/dsp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/branch.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/unimp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/formats.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/tlbop.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/fp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/decoder.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/bitfields.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/base.isa:// the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/isa/main.isa:// the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/dsp.cc: * the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/faults.cc: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/pagetable.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/system.cc: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/vtophys.hh: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/arch/mips/regfile.cc: * the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/bare_iron
Re: [m5-dev] License
I think the question is it OK with the legal dept of FSU? Ali On Mar 18, 2008, at 7:23 PM, Stephen Hines wrote: I only copied/pasted the license for anything that says FSU on it. If it needs to be changed, it is ok with me. Steve -- Stephen Hines [EMAIL PROTECTED] http://www.cs.fsu.edu/~hines On Tue, 18 Mar 2008, nathan binkert wrote: Ok, I got the following license approved. HP isn't mentioned except for the copyright line. We now need to get UM, FSU, and MIPS to agree to this. Ali/Steve: Can you take care of UM? Steve H: Can you take care of FSU? Korey: Can you take care of MIPS? This would HUGELY simplify things. Nate - Copyright (c) 2007 Hewlett-Packard Company All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the copyright holders nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] Unprintable characters in license files
Yea... I'm fine with it. Ali On Mar 18, 2008, at 10:51 PM, nathan binkert wrote: Given that this was sent before I sent the license update, am I correct in assuming that the new license is OK with you Ali? Also, Korey, make sure that you let the MIPS people know that HP has approved the license. That might make their lawyers feel a bit more at ease. Nate On Tue, Mar 18, 2008 at 1:41 PM, Ali Saidi [EMAIL PROTECTED] wrote: What about replacing company/university name with, above mentioned copyright holders, or something similar. That seems to solve both problems, Ali On Mar 17, 2008, at 5:51 PM, nathan binkert wrote: I've asked my lawyer if I can remove the HEWLETT-PACKARD COMPANY part from the body of the license. If they agree, then we need to get UM and FSU and MIPS to agree. Nate On Mon, Mar 17, 2008 at 2:38 PM, Ali Saidi [EMAIL PROTECTED] wrote: On Mar 17, 2008, at 1:52 PM, Korey Sewell wrote: looks like the characters it doesnt like are just quotation marks... so MIPS instead of ??MIPS??... Should be some find/replace work to fix this up... How does the X copyright holders thing work? We need to figure that out. Nate? Steve? How can we get to a place where we can have (c) 200X University of Michigan (c) 200X MIPS (c) 200X FSU instead of 100 lines of license? Ali On Tue, Mar 11, 2008 at 1:15 AM, Ali Saidi [EMAIL PROTECTED] wrote: Also, we really need to be able to just append the X copyright holders to the same bsd license blurb if everyone is using the same thing. 100 lines of license text and 25 lines of actual code is ridiculous. What needs to be done to do that? Ali src/base/loader/hex_file.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta_cchip.hh: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta_cchip.cc: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/dev/mips/malta.hh: * the name of MIPS Technologies, Inc. (?? MIPS??) is not used in any src/arch/mips/pra_constants.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/utility.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/linux/linux.cc: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/linux/linux.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/linux/process.cc: * the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/mips_core_specific.hh: * the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/mips_core_specific.cc: * the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/utility.cc: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/MipsCPU.py:# the name of MIPS Technologies, Inc. ((B! HMIPS(B!I) is not used in any src/arch/mips/faults.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/system.hh: * the name of MIPS Technologies, Inc. (B! HMIPSB!I) is not used in any src/arch/mips/isa/includes.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/operands.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/mem.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/noop.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/int.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/mt.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/control.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/util.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/trap.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/dsp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/branch.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch/mips/isa/formats/unimp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/formats.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/tlbop.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/formats/fp.isa:// the name of MIPS Technologies, Inc. ((B!HMIPS(B!I) is not used in any src/arch/mips/isa/decoder.isa:// the name of MIPS Technologies, Inc. (B!HMIPSB!I) is not used in any src/arch
Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all
On Mar 23, 2008, at 5:32 PM, nathan binkert wrote: scons: *** [build/SPARC_FS/params/params_wrap.cc] Error 1 Looks like this was just a pool glitch... I reran the script and it biult fine. This is actually due to a missing dependency that I found/fixed last night. I'll commit it as soon as I have the licenses sorted out. I think we have all of the HP stuff sorted out (at least Gabe says he'll give me the data I need tonight.) What's the status of UM/FSU/MIPS? scons: *** [build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/o3- timing/stdout] Error 3 The pool node just hung up on the connection... I'm rerunning on zizzer directly to see what I get there. These glitches seem to happen a lot. What failures are most common tests blowing up or compile failures? I've developed a better way to use a simulation pool for compiling using distcc that could easily be ported to OAR. It should at least fix the compile problems since distcc can recover from errors. Anyway, I've got to get my stuff working on our simulation farm, so if anyone can give any pointers as to why this fails, I can probably fix them The problem is oar closing the interactive shell before gzip finished. I imagine it only effects gzip because it's one of the longest running benchmarks we have. The release notes for a new version of oar say that a bug was fixed with walltime. I upgraded oar and specified wall time in a more standard manner. I guess we'll see if that fixes it. Ali Happy Easter! You too! Nate ___ 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] [PATCH] SCons version checking code
I moved some things around to make this work. Unfortunately, diff made
the changset look a lot bigger than it really is.
Ali
On Apr 5, 2008, at 2:06 PM, Ali Saidi wrote:
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1207418753 14400
# Node ID 9866ed2a8ed2edb9f591f8abab2e4625ffb9dafa
# Parent eca80b56f4fd5a92720415d49a7cf25a2de2122a
[mq]: scons_ver.diff
diff --git a/SConstruct b/SConstruct
--- a/SConstruct
+++ b/SConstruct
@@ -65,6 +65,7 @@
import sys
import os
+import re
from os.path import isdir, isfile, join as joinpath
@@ -82,78 +83,10 @@ EnsurePythonVersion(2,4)
# Python 2.4.
import subprocess
-# Ironically, SCons 0.96 dies if you give EnsureSconsVersion a
-# 3-element version number.
-min_scons_version = (0,96,91)
-try:
-EnsureSConsVersion(*min_scons_version)
-except:
-print Error checking current SCons version.
-print SCons, ..join(map(str,min_scons_version)), or
greater required.
-Exit(2)
-
-
-# The absolute path to the current directory (where this file lives).
-ROOT = Dir('.').abspath
-
-# Path to the M5 source tree.
-SRCDIR = joinpath(ROOT, 'src')
-
-# tell python where to find m5 python code
-sys.path.append(joinpath(ROOT, 'src/python'))
-
-def check_style_hook(ui):
-ui.readconfig(joinpath(ROOT, '.hg', 'hgrc'))
-style_hook = ui.config('hooks', 'pretxncommit.style', None)
-
-if not style_hook:
-print \
-You're missing the M5 style hook.
-Please install the hook so we can ensure that all code fits a
common style.
-
-All you'd need to do is add the following lines to your
repository .hg/hgrc
-or your personal .hgrc
-
-
-[extensions]
-style = %s/util/style.py
-
-[hooks]
-pretxncommit.style = python:style.check_whitespace
- % (ROOT)
-sys.exit(1)
-
-if ARGUMENTS.get('IGNORE_STYLE') != 'True' and isdir(joinpath(ROOT,
'.hg')):
-try:
-from mercurial import ui
-check_style_hook(ui.ui())
-except ImportError:
-pass
-
-###
-#
-# Figure out which configurations to set up based on the path(s) of
-# the target(s).
-#
-###
-
-# Find default configuration binary.
-Default(os.environ.get('M5_DEFAULT_BINARY', 'build/ALPHA_SE/
m5.debug'))
-
-# helper function: find last occurrence of element in list
-def rfind(l, elt, offs = -1):
-for i in range(len(l)+offs, 0, -1):
-if l[i] == elt:
-return i
-raise ValueError, element not found
-
-# helper function: compare dotted version numbers.
-# E.g., compare_version('1.3.25', '1.4.1')
+# helper function: compare arrays of version numbers.
+# E.g., compare_version((1,3,25), (1,4,1)')
# returns -1, 0, 1 if v1 is , ==, v2
def compare_versions(v1, v2):
-# Convert dotted strings to lists
-v1 = map(int, v1.split('.'))
-v2 = map(int, v2.split('.'))
# Compare corresponding elements of lists
for n1,n2 in zip(v1, v2):
if n1 n2: return -1
@@ -162,6 +95,113 @@ def compare_versions(v1, v2):
if len(v1) len(v2): return -1
if len(v1) len(v2): return 1
return 0
+
+# helper function: compare dotted version numbers.
+# E.g., compare_version('1.3.25', '1.4.1')
+# returns -1, 0, 1 if v1 is , ==, v2
+def compare_str_versions(v1, v2):
+# Convert dotted strings to lists
+v1 = map(int, v1.split('.'))
+v2 = map(int, v2.split('.'))
+return compare_versions(v1,v2)
+
+
+# SCons version numbers need special processing because they can have
+# charecters and an release date embedded in them. This function does
+# the magic to extract them in a similar way to the SCons internal
function
+# function does and then checks that the current version is not
contained in
+# a list of version tuples (bad_ver_strs)
+def CheckSCons(bad_ver_strs):
+def scons_ver(v):
+num_parts = v.split(' ')[0].split('.')
+major = int(num_parts[0])
+minor = int(re.match('\d+', num_parts[1]).group())
+rev = 0
+rdate = 0
+if len(num_parts) 2:
+try: rev = int(re.match('\d+', num_parts[2]).group())
+except: pass
+rev_parts = num_parts[2].split('d')
+if len(rev_parts) 1:
+rdate = int(re.match('\d+', rev_parts[1]).group())
+
+return (major, minor, rev, rdate)
+
+sc_ver = scons_ver(SCons.__version__)
+for bad_ver in bad_ver_strs:
+bv = (scons_ver(bad_ver[0]), scons_ver(bad_ver[1]))
+if compare_versions(sc_ver, bv[0]) != -1 and\
+compare_versions(sc_ver, bv[1]) != 1:
+print The version of SCons that you have installed: ,
SCons.__version__
+print has a bug that prevents it from working
correctly with M5.
+print Please install a version NOT contained within
the following,
+print ranges (inclusive):
+for bad_ver in bad_ver_strs:
+print %s - %s % bad_ver
+Exit(2
Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all
Ahh... I get it. We don't pass the BATCH_CMD command into the lower level SConscripts to libelf doesn't get built with qdo2. That would be ok, except that zizzer is now a 64 bit host. Ali On Apr 6, 2008, at 3:10 PM, Ali Saidi wrote: This happened because some how build/libelf/ was compiled on a 64bit host while the rest was being compiled on 32bit hosts. Did anyone manually run the compile from the poolfs directory? Otherwise I don't understand how it could have happened. There is a separate directory for builds that run on zizzer. Ali On Apr 6, 2008, at 3:07 AM, Cron Daemon wrote: scons: *** [build/ALPHA_SE/m5.fast.bin] Error 1 scons: *** [build/ALPHA_FS/m5.fast.bin] Error 1 scons: *** [build/MIPS_SE/m5.fast.bin] Error 1 scons: *** [build/SPARC_SE/m5.fast.bin] Error 1 ['g++', '-o', 'build/SPARC_FS/m5.fast.bin', 'build/SPARC_FS/arch/ sparc/asi.fo', 'build/SPARC_FS/arch/sparc/faults.fo', 'build/ SPARC_FS/arch/sparc/floatregfile.fo', 'build/SPARC_FS/arch/sparc/ intregfile.fo', 'build/SPARC_FS/arch/sparc/miscregfile.fo', 'build/ SPARC_FS/arch/sparc/pagetable.fo', 'build/SPARC_FS/arch/sparc/ regfile.fo', 'build/SPARC_FS/arch/sparc/remote_gdb.fo', 'build/ SPARC_FS/arch/sparc/tlb.fo', 'build/SPARC_FS/arch/sparc/ utility.fo', 'build/SPARC_FS/arch/sparc/stacktrace.fo', 'build/ SPARC_FS/arch/sparc/system.fo', 'build/SPARC_FS/arch/sparc/ ua2005.fo', 'build/SPARC_FS/arch/sparc/vtophys.fo', 'build/SPARC_FS/ arch/sparc/decoder.fo', 'build/SPARC_FS/arch/sparc/ atomic_simple_cpu_exec.fo', 'build/SPARC_FS/arch/sparc/ timing_simple_cpu_exec.fo', 'build/SPARC_FS/base/annotate.fo', 'build/SPARC_FS/base/bigint.fo', 'build/SPARC_FS/base/ circlebuf.fo', 'build/SPARC_FS/base/cprintf.fo', 'build/SPARC_FS/ base/crc.fo', 'build/SPARC_FS/base/fast_alloc.fo', 'build/SPARC_FS/ base/! fenv.fo', 'build/SPARC_FS/base/fifo_buffer.fo', 'build/SPARC_FS/ base/hostinfo.fo', 'build/SPARC_FS/base/hybrid_pred.fo', 'build/ SPARC_FS/base/inet.fo', 'build/SPARC_FS/base/inifile.fo', 'build/ SPARC_FS/base/intmath.fo', 'build/SPARC_FS/base/match.fo', 'build/ SPARC_FS/base/misc.fo', 'build/SPARC_FS/base/output.fo', 'build/ SPARC_FS/base/pollevent.fo', 'build/SPARC_FS/base/random.fo', 'build/SPARC_FS/base/random_mt.fo', 'build/SPARC_FS/base/range.fo', 'build/SPARC_FS/base/remote_gdb.fo', 'build/SPARC_FS/base/ sat_counter.fo', 'build/SPARC_FS/base/socket.fo', 'build/SPARC_FS/ base/statistics.fo', 'build/SPARC_FS/base/str.fo', 'build/SPARC_FS/ base/time.fo', 'build/SPARC_FS/base/trace.fo', 'build/SPARC_FS/base/ userinfo.fo', 'build/SPARC_FS/base/compression/ lzss_compression.fo', 'build/SPARC_FS/base/loader/aout_object.fo', 'build/SPARC_FS/base/loader/ecoff_object.fo', 'build/SPARC_FS/base/ loader/elf_object.fo', 'build/SPARC_FS/base/loader/hex_file.fo', 'build/SPARC_FS/base/loader/ob! ject_file.fo', 'build/SPARC_FS/base/loader/raw_object.fo', 'build/ SPAR C_FS/base/loader/symtab.fo', 'build/SPARC_FS/base/stats/events.fo', 'build/SPARC_FS/base/stats/output.fo', 'build/SPARC_FS/base/stats/ statdb.fo', 'build/SPARC_FS/base/stats/text.fo', 'build/SPARC_FS/ base/stats/visit.fo', 'build/SPARC_FS/cpu/activity.fo', 'build/ SPARC_FS/cpu/base.fo', 'build/SPARC_FS/cpu/cpuevent.fo', 'build/ SPARC_FS/cpu/exetrace.fo', 'build/SPARC_FS/cpu/func_unit.fo', 'build/SPARC_FS/cpu/inteltrace.fo', 'build/SPARC_FS/cpu/ pc_event.fo', 'build/SPARC_FS/cpu/quiesce_event.fo', 'build/ SPARC_FS/cpu/static_inst.fo', 'build/SPARC_FS/cpu/ simple_thread.fo', 'build/SPARC_FS/cpu/thread_context.fo', 'build/ SPARC_FS/cpu/thread_state.fo', 'build/SPARC_FS/cpu/ intr_control.fo', 'build/SPARC_FS/cpu/profile.fo', 'build/SPARC_FS/ cpu/legiontrace.fo', 'build/SPARC_FS/cpu/simple/atomic.fo', 'build/ SPARC_FS/cpu/simple/timing.fo', 'build/SPARC_FS/cpu/simple/ base.fo', 'build/SPARC_FS/dev/baddev.fo', 'build/SPARC_FS/dev/ disk_image.fo', 'build/SPARC_FS/dev/etherbus.fo', 'build/SPARC_! FS/dev/etherdump.fo', 'build/SPARC_FS/dev/etherint.fo', 'build/ SPARC_FS/dev/etherlink.fo', 'build/SPARC_FS/dev/etherpkt.fo', 'build/SPARC_FS/dev/ethertap.fo', 'build/SPARC_FS/dev/ i8254xGBe.fo', 'build/SPARC_FS/dev/ide_ctrl.fo', 'build/SPARC_FS/ dev/ide_disk.fo', 'build/SPARC_FS/dev/io_device.fo', 'build/ SPARC_FS/dev/isa_fake.fo', 'build/SPARC_FS/dev/mc146818.fo', 'build/ SPARC_FS/dev/ns_gige.fo', 'build/SPARC_FS/dev/pciconfigall.fo', 'build/SPARC_FS/dev/pcidev.fo', 'build/SPARC_FS/dev/pktfifo.fo', 'build/SPARC_FS/dev/platform.fo', 'build/SPARC_FS/dev/ simconsole.fo', 'build/SPARC_FS/dev/simple_disk.fo', 'build/ SPARC_FS/dev/sinic.fo', 'build/SPARC_FS/dev/uart.fo', 'build/ SPARC_FS/dev/uart8250.fo', 'build/SPARC_FS/dev/sparc/dtod.fo', 'build/SPARC_FS/dev/sparc/iob.fo', 'build/SPARC_FS/dev/sparc/ t1000.fo', 'build/SPARC_FS/dev/sparc/mm_disk.fo', 'build/SPARC_FS/ kern/kernel_stats.fo', 'build/SPARC_FS/kern/system_events.fo', 'build/SPARC_FS/kern/linux/events.fo', 'build/SPARC_FS/kern! /linux/linux_syscalls.fo', 'build
Re: [m5-dev] Notification from M5 Bugs
Please update the bug as appropriate then. Thanks, Ali On Apr 11, 2008, at 2:05 PM, Gabe Black wrote: makeExtMI no longer exists. It was absorbed into the predecoder and uses the thread context to get whatever state it needs. This state is the committed state, I believe, so it would miss younger speculative execution. Gabe Flyspray wrote: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The new details are below. For full information about what has changed, visit the URL and click the History tab. FS#192 - Fix makeExtMI to be more flexible with ISAs User who did this: - Ali Saidi (saidi) Attached to Project - M5 Bugs Summary - Fix makeExtMI to be more flexible with ISAs Task Type - Bug Category - CPU Status - New Assigned To - Kevin Lim Operating System - All Severity - Medium Priority - Normal Reported Version - 1.1 Due in Version - Due Date - Undecided Percent Complete - 0% Details - Currently makeExtMI is defined differently per-ISA, forcing an if-def on the ISA in the CPU's fetch code. It'd be nice to fix this. Some possibilities: Make ThreadContext for fetch stage. This might be a little overkill for one function. Have makeExtMI take in a fetch object, or fetch data structure that has the necessary information for making the extended MI. This might force other models such as SimpleCPU to create a fetch object. More information can be found at the following URL: http://www.m5sim.org/flyspray/task/192 You are receiving this message because you have requested it from the Flyspray bugtracking system. You can be removed from future notifications by visiting the URL shown above. ___ 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] Notification from M5 Bugs
I'm moving bugs from the internal bug tracker to the external one. Ali On Apr 11, 2008, at 2:10 PM, Gabe Black wrote: What about this changed? Gabe Flyspray wrote: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The new details are below. For full information about what has changed, visit the URL and click the History tab. FS#126 - SPARC ISA support User who did this: - Ali Saidi (saidi) Attached to Project - M5 Bugs Summary - SPARC ISA support Task Type - Major Feature Category - ISA Support Status - Assigned Assigned To - Gabe Black Operating System - All Severity - High Priority - Normal Reported Version - head Due in Version - 2.1 Due Date - Undecided Percent Complete - 70% Details - SPARC More information can be found at the following URL: http://www.m5sim.org/flyspray/task/126 You are receiving this message because you have requested it from the Flyspray bugtracking system. You can be removed from future notifications by visiting the URL shown above. ___ 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
[m5-dev] while trying to upgrade flyspray I broke it...
I'll fix it soon. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] while trying to upgrade flyspray I broke it...
It's back up... If you get a redirection error you need to clear your cookies. Ali On Apr 11, 2008, at 3:05 PM, Ali Saidi wrote: I'll fix it soon. Ali ___ 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] Bugs/Tasks
Everyone, We've moved all of the outstanding tasks and bugs from our internal bug tracker to flyspray at: http://www.m5sim.org/flyspray/ We list the various features and bugs and what release we would like them to by done by. If you have any suggestions, comments please add them and if you would like to help out please feel free to spend some time squashing outstanding issues. Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? 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
Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression --scratch all
The failed I would guess is a real error. The time out is just because that test takes over 6 hours on the pool nodes and qdo times out. Ali On Apr 27, 2008, at 1:34 PM, Gabe Black wrote: Are these real errors or pool errors? Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/ o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple- timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-atomic-dual passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/ memtest passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple- atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/ twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple- atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple- atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple- timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/ simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3- timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/ simple-atomic passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple- timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple- timing passed. * build/SPARC_SE/tests/fast/long/50.vortex/sparc/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple- timing passed. * build/SPARC_SE/tests/fast/long/70.twolf/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/long/10.mcf/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/long/50.vortex/sparc/linux/simple- timing passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/o3- timing passed. * build/SPARC_SE/tests/fast/long/70.twolf/sparc/linux/simple- timing passed. * build/SPARC_SE/tests/fast/long/10.mcf/sparc/linux/simple- timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple- atomic passed. * build/X86_SE/tests/fast/long/70.twolf/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/long/10.mcf/x86/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple- timing passed. * build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/simple- timing passed. * build/X86_SE/tests/fast/long/20.parser/x86/linux/simple- atomic FAILED! * build/X86_SE/tests/fast/long/00.gzip/x86/linux/simple-atomic passed. * build/SPARC_FS/tests/fast/long/80.solaris-boot/sparc/solaris/ t1000-simple-atomic passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/o3-timing passed. * build/X86_SE/tests/fast/long/60.bzip2/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/o3-timing passed. scons: *** [build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/o3- timing/stdout] Error 3 See /z/m5/regression/regress-2008-04-27-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org
[m5-dev] m5: SCons: More scons fixing for SCons bug 2006
changeset 7738a042628b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7738a042628b
summary: SCons: More scons fixing for SCons bug 2006
diffstat:
1 file changed, 6 insertions(+)
src/kern/SConscript |6 ++
diffs (13 lines):
diff -r e4987b6ca365 -r 7738a042628b src/kern/SConscript
--- a/src/kern/SConscript Thu Apr 10 15:38:10 2008 -0400
+++ b/src/kern/SConscript Tue May 06 16:22:14 2008 -0400
@@ -48,3 +48,9 @@ if env['FULL_SYSTEM']:
Source('tru64/tru64_syscalls.cc')
TraceFlag('BADADDR')
+# Workaround for bug in SCons version 0.97d20071212
+# Scons bug id: 2006 M5 Bug id: 308
+else:
+Dir('linux')
+if env['TARGET_ISA'] == 'alpha':
+Dir('tru64')
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] m5: Make sure that output files are always checked success befor...
changeset 1af0b428ac2f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1af0b428ac2f
summary: Make sure that output files are always checked success before they're
used.
diffstat:
5 files changed, 14 insertions(+), 14 deletions(-)
src/base/output.cc |4 ++--
src/base/output.hh |3 ++-
src/dev/etherdump.cc| 14 +++---
src/dev/etherdump.hh|2 +-
src/mem/cache/tags/split.cc |5 ++---
diffs (118 lines):
diff -r 7738a042628b -r 1af0b428ac2f src/base/output.cc
--- a/src/base/output.ccTue May 06 16:22:14 2008 -0400
+++ b/src/base/output.ccThu May 15 19:10:26 2008 -0400
@@ -98,7 +98,7 @@ OutputDirectory::create(const string na
ofstream *file = new ofstream(resolve(name).c_str(),
ios::trunc | binary ? ios::binary : (ios::openmode)0);
if (!file-is_open())
-panic(Cannot open file %s, name);
+fatal(Cannot open file %s, name);
return file;
}
@@ -119,7 +119,7 @@ OutputDirectory::find(const string name
ofstream *file = new ofstream(filename.c_str(), ios::trunc);
if (!file-is_open())
-panic(Cannot open file %s, filename);
+fatal(Cannot open file %s, filename);
files[filename] = file;
return file;
diff -r 7738a042628b -r 1af0b428ac2f src/base/output.hh
--- a/src/base/output.hhTue May 06 16:22:14 2008 -0400
+++ b/src/base/output.hhThu May 15 19:10:26 2008 -0400
@@ -42,6 +42,8 @@ class OutputDirectory
map_t files;
std::string dir;
+
+std::string resolve(const std::string name);
public:
OutputDirectory();
@@ -50,7 +52,6 @@ class OutputDirectory
void setDirectory(const std::string dir);
const std::string directory();
-std::string resolve(const std::string name);
std::ostream *create(const std::string name, bool binary = false);
std::ostream *find(const std::string name);
diff -r 7738a042628b -r 1af0b428ac2f src/dev/etherdump.cc
--- a/src/dev/etherdump.cc Tue May 06 16:22:14 2008 -0400
+++ b/src/dev/etherdump.cc Thu May 15 19:10:26 2008 -0400
@@ -45,7 +45,7 @@ using std::string;
using std::string;
EtherDump::EtherDump(const Params *p)
-: SimObject(p), stream(simout.resolve(p-file).c_str()),
+: SimObject(p), stream(simout.create(p-file, true)),
maxlen(p-maxlen)
{
}
@@ -86,7 +86,7 @@ EtherDump::init()
hdr.sigfigs = 0;
hdr.linktype = DLT_EN10MB;
-stream.write(reinterpret_castchar *(hdr), sizeof(hdr));
+stream-write(reinterpret_castchar *(hdr), sizeof(hdr));
/*
* output an empty packet with the current time so that we know
@@ -98,9 +98,9 @@ EtherDump::init()
pkthdr.microseconds = 0;
pkthdr.caplen = 0;
pkthdr.len = 0;
-stream.write(reinterpret_castchar *(pkthdr), sizeof(pkthdr));
+stream-write(reinterpret_castchar *(pkthdr), sizeof(pkthdr));
-stream.flush();
+stream-flush();
}
void
@@ -111,9 +111,9 @@ EtherDump::dumpPacket(EthPacketPtr pack
pkthdr.microseconds = (curTick / Clock::Int::us) % ULL(100);
pkthdr.caplen = std::min(packet-length, maxlen);
pkthdr.len = packet-length;
-stream.write(reinterpret_castchar *(pkthdr), sizeof(pkthdr));
-stream.write(reinterpret_castchar *(packet-data), pkthdr.caplen);
-stream.flush();
+stream-write(reinterpret_castchar *(pkthdr), sizeof(pkthdr));
+stream-write(reinterpret_castchar *(packet-data), pkthdr.caplen);
+stream-flush();
}
EtherDump *
diff -r 7738a042628b -r 1af0b428ac2f src/dev/etherdump.hh
--- a/src/dev/etherdump.hh Tue May 06 16:22:14 2008 -0400
+++ b/src/dev/etherdump.hh Thu May 15 19:10:26 2008 -0400
@@ -46,7 +46,7 @@ class EtherDump : public SimObject
class EtherDump : public SimObject
{
private:
-std::ofstream stream;
+std::ostream *stream;
const int maxlen;
void dumpPacket(EthPacketPtr packet);
void init();
diff -r 7738a042628b -r 1af0b428ac2f src/mem/cache/tags/split.cc
--- a/src/mem/cache/tags/split.cc Tue May 06 16:22:14 2008 -0400
+++ b/src/mem/cache/tags/split.cc Thu May 15 19:10:26 2008 -0400
@@ -379,13 +379,12 @@ Split::cleanupRefs()
else if (lru_net)
lru_net-cleanupRefs();
-ofstream memPrint(simout.resolve(memory_footprint.txt).c_str(),
- ios::trunc);
+ostream *memPrint = simout.create(memory_footprint.txt);
// this shouldn't be here but it happens at the end, which is what i want
memIter end = memHash.end();
for (memIter iter = memHash.begin(); iter != end; ++iter) {
-ccprintf(memPrint, %8x\t%d\n, (*iter).first, (*iter).second);
+ccprintf(*memPrint, %8x\t%d\n, (*iter).first, (*iter).second);
}
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] upstream changeset in output
That wouldn't be ideal because we would need to emulate everything Object() is doing to get the c compiler and options right. Here is take two on the hg version diff. It creates a file which is dependent on all the other objects in the system. So if you make a change to the repository nothing will be recompiled. To get the right info I need to use os.getcwd(). That works in the default case but I don't know how it interacts with Nate's compiling script. Worst case it just print the Hg revision as Unknown, however I can't seem to pass the SConscript root directory to the builder that builds hginfo.cc without it setting up a circular dependency that I can't get rid of. Ali hgver2.diff Description: Binary data On May 21, 2008, at 5:47 PM, Nathan Binkert wrote: We could just provide our own action that is both a file generation and a compile. On May 21, 2008, at 2:05 PM, Ali Saidi [EMAIL PROTECTED] wrote: We can't because the date is created by the compiler with the __DATE__ __TIME__ macros. The only way to do something like this would be create a dummy file that we write a string to in the SConscript. We can set it's dependencies to be all other objects, but I don't know if we can remove the dependence on itself (it's changed so why shouldn't a new object file be created?). Ali On May 21, 2008, at 4:59 PM, Nathan Binkert wrote: What exactly are you trying to do? Stick the changset in the output? If so, do it how we do the date. On May 21, 2008, at 1:12 PM, Ali Saidi [EMAIL PROTECTED] wrote: This diff stamps a file adds the mercurial id to the output, however Nate complained that if the revision in the working directory changed (which could happen if you qdeleted a patch) then you would have to recompile (although not much just a re- linking). Something that could fix that (that I didn't try) would be to remove the build dependency from that file, but you would have to add a dependency to every other file in the build that would execute some python that would cause that file to regenerated. Ali hgver.diff On May 21, 2008, at 4:08 PM, Gabe Black wrote: I've been thinking about how this could actually be done, and it seems to me that there could be a hook in the head (hooks are propagated, right?) which adjusted a header file every time a changeset was pushed into the head to have that hex value in a variable. The adjustment to the header file would be part of the changeset so that moving around revisions would keep it consistent, and I don't know if you could really do it any other way. That would ensure that unless the downstream users explicitly modify that header file for some reason, which would be a little weird, the output would reflect the last changeset that was stamped by the root. One downside to all this is that that file would change constantly and clutter the history and the repository metadata. 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 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] upstream changeset in output
Well, I imagine most people will use mercurial at least to check out the code in which case we'll have the last ID. Perhaps we want to include the qbase revision as well incase lot of people use MQ. Speaking of which when the repository is made available we probably want a pretty good little e-mali tutorial that pitches the right way to do things as using MQ on top of the repository. I don't really like the idea of having a hook that introduces its own changesets into the repository. Anything we add needs to be a manipulation of the data in the mercurial directory. Ali On May 22, 2008, at 8:56 PM, Gabe Black wrote: As I said in an email earlier, you had pointed out that if somebody sends in the output of m5, it's nice to be able to easily tell it's beta 4 or beta 3 or somewhere in the middle and they, for instance, might need the cache patches without having to go back and forth teasing out details. My gut says a lot of people won't take advantage of mercurial so the current revision will likely be the same as the mainline one, but it might be useful. It could also be handy to easily tell what changesets from the mainline you're binary was compiled with assuming you have patches on top of it. It's something that could be handy although I'm sure we'd survive without it. Gabe Ali Saidi wrote: Why do we care about the central repository version? Ali On May 22, 2008, at 8:13 PM, Gabe Black wrote: So anyway, now that we seem to have the current version in there, what about the original question which was about the latest mainline revision? Ali Saidi wrote: That wouldn't be ideal because we would need to emulate everything Object() is doing to get the c compiler and options right. Here is take two on the hg version diff. It creates a file which is dependent on all the other objects in the system. So if you make a change to the repository nothing will be recompiled. To get the right info I need to use os.getcwd(). That works in the default case but I don't know how it interacts with Nate's compiling script. Worst case it just print the Hg revision as Unknown, however I can't seem to pass the SConscript root directory to the builder that builds hginfo.cc without it setting up a circular dependency that I can't get rid of. Ali On May 21, 2008, at 5:47 PM, Nathan Binkert wrote: We could just provide our own action that is both a file generation and a compile. On May 21, 2008, at 2:05 PM, Ali Saidi [EMAIL PROTECTED] wrote: We can't because the date is created by the compiler with the __DATE__ __TIME__ macros. The only way to do something like this would be create a dummy file that we write a string to in the SConscript. We can set it's dependencies to be all other objects, but I don't know if we can remove the dependence on itself (it's changed so why shouldn't a new object file be created?). Ali On May 21, 2008, at 4:59 PM, Nathan Binkert wrote: What exactly are you trying to do? Stick the changset in the output? If so, do it how we do the date. On May 21, 2008, at 1:12 PM, Ali Saidi [EMAIL PROTECTED] wrote: This diff stamps a file adds the mercurial id to the output, however Nate complained that if the revision in the working directory changed (which could happen if you qdeleted a patch) then you would have to recompile (although not much just a re-linking). Something that could fix that (that I didn't try) would be to remove the build dependency from that file, but you would have to add a dependency to every other file in the build that would execute some python that would cause that file to regenerated. Ali hgver.diff On May 21, 2008, at 4:08 PM, Gabe Black wrote: I've been thinking about how this could actually be done, and it seems to me that there could be a hook in the head (hooks are propagated, right?) which adjusted a header file every time a changeset was pushed into the head to have that hex value in a variable. The adjustment to the header file would be part of the changeset so that moving around revisions would keep it consistent, and I don't know if you could really do it any other way. That would ensure that unless the downstream users explicitly modify that header file for some reason, which would be a little weird, the output would reflect the last changeset that was stamped by the root. One downside to all this is that that file would change constantly and clutter the history and the repository metadata. 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5
[m5-dev] linux/patches: M5 Struct: add two missing symbols for M5 ThreadInfo
changeset 3db61f7be690 in /z/repo/linux/patches details: http://m5sim.org/repolinux/patches?cmd=changeset;node=3db61f7be690 summary: M5 Struct: add two missing symbols for M5 ThreadInfo diffstat: 1 file changed, 3 insertions(+), 1 deletion(-) m5/m5struct.diff |4 +++- diffs (20 lines): diff -r 5a158de4281e -r 3db61f7be690 m5/m5struct.diff --- a/m5/m5struct.diff Tue Jan 15 23:16:40 2008 -0500 +++ b/m5/m5struct.diff Mon May 26 00:24:14 2008 -0400 @@ -16,7 +16,7 @@ new file mode 100644 new file mode 100644 --- /dev/null +++ b/kernel/m5struct.c -@@ -0,0 +1,44 @@ +@@ -0,0 +1,46 @@ +/* + * Copyright (c) 2005 + * The Regents of The University of Michigan @@ -59,5 +59,7 @@ new file mode 100644 + +const int task_struct_size = sizeof(struct task_struct); +const int task_struct_pid = offsetof(struct task_struct, pid); ++const int task_struct_start_time = offsetof(struct task_struct, start_time); +const int task_struct_comm = offsetof(struct task_struct, comm); ++const int task_struct_comm_size = TASK_COMM_LEN; + ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] panic vs. fatal
On May 28, 2008, at 11:23 AM, nathan binkert wrote: panic() -- An assert that isn't compiled out fatal() -- some configuration parameter caused a problem Ok, I thought so. Do we want to keep these names? I will promise that I have learned finally, but the names seem a bit to synonymous to me. I will go through my code and convert the proper things to fatal since I am at fault for not doing this correctly. Does everyone else seem to do this stuff correctly, or should we go through more of them? I just learned them and they make sense to me. I would also like to add an option to allow panic and fatal (or whatever their replacements) to raise exceptions into the python so we can get a stack trace. I don't know if this influences any thoughts on this. I spent some time trying to do this, if you remember.I never got it to work correctly from inside of m5, but perhaps someone else would have better luck. Can't we make the error messages themselves descriptive, rather than requiring a two step process? Well, something like the stat check error needs more description, and a link to the wiki page would be useful. We could do it only for the error messages that are necessary of course, but it seems that some of the error messages should have a lot more information. Most of these errors panic in the c++ and call _exit(). I don't think people are seeing python error messages that often. I think some of the configuration script things could be trapped in python. I don't know if it's worth spending time adding more indirection to the error path so python can print an error. If the error is fatal python isn't going to be able to correct it and continue. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] when to fake BIOS initialization
Why can't you just stick it in the constructor? You'll need to serialize that timer value when a checkpoint is dropped and create an event when the checkpoint is restored from, but you would need to do that anyway. You can take a look at how we serialize the PIT for an idea. Ali On May 30, 2008, at 6:12 PM, Gabe Black wrote: The kernel is assuming that timer 0 has been set up to count with a period of 0 (which is effectively 0x, it's maximum value) by the BIOS during system bring up. It's trying to watch the value of the timers count in order to switch from using the PIT for interrupts to the APIC right after the timer goes off/wraps around. This is all fine, except the BIOS never runs so the timer never gets set up, the count never changes, and the kernel hangs. What I need to do is to go in and fake the initialization as if the BIOS had done something, but I need to make sure it works with checkpointing and all that so I can't just stick it in a constructor. What do people think is a good place to do that? I'm thinking of making it the platform objects responsibility but the system object is the one that knows when things are coming up, right? I'm only really aware of ways to bring up the CPUs and not how to do ISA specific initialization of the system/platform/whatever else. 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
Re: [m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick
It's because the repository isn't where it should be, so the regression script just errors out on something near the first line. Ali On Jun 2, 2008, at 3:24 AM, Gabe Black wrote: This doesn't seem very helpful... Cron Daemon wrote: See /z/m5/regression/regress-2008-06-02-03:00:01 for details. ___ 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] Test Repository
What if it's supposed to be UM and MIPS? [(UM, [2006], ['Blah']), (MIPS, [2007], ['Foo'])] ?? Ali On Jun 1, 2008, at 4:34 PM, nathan binkert wrote: Looking through the mips directory for files that are just copyright MIPS and not UM interrupts.cc seems to be derived from alpha/interrupts.hh linux/linux.hh is exactly the same as alpha/linux/linux.hh with some constants changed linux/linux.cc is s/AlphaLinux/MipsLinux/g of alpha/linux/linux.cc mips_core_specific.cc is ev5.cc with most of the code commented out utility.cc has 25 lines verbatim from alpha/utility.cc regfile.cc is very similar to sparc/regfile.cc For those files, are you willing to give me code that has what the copyrights should be? It should look like this: (There are constants called UM and MIPS that you can use instead of the full institution name) 'src/dev/mips/MipsConsole.py' : [(UM, [2007], ['Korey Sewell'])], 'src/dev/sparc/T1000.py' : [(UM, [2006,2007], ['Gabe Black'])], Thanks, Nate ___ 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] linux/patches: Add Linux 2.6.22 default config
changeset 3768873ebbc6 in /z/repo/linux/patches details: http://m5sim.org/repolinux/patches?cmd=changeset;node=3768873ebbc6 summary: Add Linux 2.6.22 default config diffstat: 2 files changed, 1059 insertions(+) m5/defaultconfig_2.6.22.diff | 1058 ++ series |1 diffs (truncated from 1073 to 300 lines): diff -r 3db61f7be690 -r 3768873ebbc6 m5/defaultconfig_2.6.22.diff --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/m5/defaultconfig_2.6.22.diff Mon Jun 02 21:01:49 2008 -0400 @@ -0,0 +1,1058 @@ +diff --git a/.config.m5 b/.config.m5 +new file mode 100644 +--- /dev/null b/.config.m5 +@@ -0,0 +1,1053 @@ ++# ++# Automatically generated make config: don't edit ++# Linux kernel version: 2.6.22.2 ++# Mon Jun 2 20:55:10 2008 ++# ++CONFIG_ALPHA=y ++CONFIG_64BIT=y ++CONFIG_MMU=y ++CONFIG_RWSEM_XCHGADD_ALGORITHM=y ++# CONFIG_ARCH_HAS_ILOG2_U32 is not set ++# CONFIG_ARCH_HAS_ILOG2_U64 is not set ++CONFIG_GENERIC_FIND_NEXT_BIT=y ++CONFIG_GENERIC_CALIBRATE_DELAY=y ++CONFIG_ZONE_DMA=y ++CONFIG_GENERIC_ISA_DMA=y ++# CONFIG_GENERIC_IOMAP is not set ++CONFIG_GENERIC_HARDIRQS=y ++CONFIG_GENERIC_IRQ_PROBE=y ++CONFIG_AUTO_IRQ_AFFINITY=y ++CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config ++ ++# ++# Code maturity level options ++# ++CONFIG_EXPERIMENTAL=y ++CONFIG_LOCK_KERNEL=y ++CONFIG_INIT_ENV_ARG_LIMIT=32 ++ ++# ++# General setup ++# ++CONFIG_LOCALVERSION= ++CONFIG_LOCALVERSION_AUTO=y ++CONFIG_SWAP=y ++CONFIG_SYSVIPC=y ++# CONFIG_IPC_NS is not set ++CONFIG_SYSVIPC_SYSCTL=y ++# CONFIG_POSIX_MQUEUE is not set ++# CONFIG_BSD_PROCESS_ACCT is not set ++# CONFIG_TASKSTATS is not set ++# CONFIG_UTS_NS is not set ++# CONFIG_AUDIT is not set ++CONFIG_IKCONFIG=y ++CONFIG_IKCONFIG_PROC=y ++CONFIG_LOG_BUF_SHIFT=15 ++# CONFIG_CPUSETS is not set ++CONFIG_SYSFS_DEPRECATED=y ++# CONFIG_RELAY is not set ++# CONFIG_BLK_DEV_INITRD is not set ++# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set ++CONFIG_SYSCTL=y ++# CONFIG_EMBEDDED is not set ++CONFIG_SYSCTL_SYSCALL=y ++CONFIG_KALLSYMS=y ++CONFIG_KALLSYMS_ALL=y ++# CONFIG_KALLSYMS_EXTRA_PASS is not set ++CONFIG_HOTPLUG=y ++CONFIG_PRINTK=y ++CONFIG_BUG=y ++CONFIG_ELF_CORE=y ++CONFIG_BASE_FULL=y ++CONFIG_FUTEX=y ++CONFIG_ANON_INODES=y ++CONFIG_EPOLL=y ++CONFIG_SIGNALFD=y ++CONFIG_TIMERFD=y ++CONFIG_EVENTFD=y ++CONFIG_SHMEM=y ++CONFIG_VM_EVENT_COUNTERS=y ++CONFIG_SLAB=y ++# CONFIG_SLUB is not set ++# CONFIG_SLOB is not set ++CONFIG_RT_MUTEXES=y ++# CONFIG_TINY_SHMEM is not set ++CONFIG_BASE_SMALL=0 ++ ++# ++# Loadable module support ++# ++CONFIG_MODULES=y ++CONFIG_MODULE_UNLOAD=y ++# CONFIG_MODULE_FORCE_UNLOAD is not set ++# CONFIG_MODVERSIONS is not set ++# CONFIG_MODULE_SRCVERSION_ALL is not set ++CONFIG_KMOD=y ++CONFIG_STOP_MACHINE=y ++ ++# ++# Block layer ++# ++CONFIG_BLOCK=y ++# CONFIG_BLK_DEV_IO_TRACE is not set ++ ++# ++# IO Schedulers ++# ++CONFIG_IOSCHED_NOOP=y ++CONFIG_IOSCHED_AS=y ++CONFIG_IOSCHED_DEADLINE=y ++CONFIG_IOSCHED_CFQ=y ++# CONFIG_DEFAULT_AS is not set ++# CONFIG_DEFAULT_DEADLINE is not set ++CONFIG_DEFAULT_CFQ=y ++# CONFIG_DEFAULT_NOOP is not set ++CONFIG_DEFAULT_IOSCHED=cfq ++ ++# ++# System setup ++# ++CONFIG_ALPHA_GENERIC=y ++# CONFIG_ALPHA_ALCOR is not set ++# CONFIG_ALPHA_XL is not set ++# CONFIG_ALPHA_BOOK1 is not set ++# CONFIG_ALPHA_AVANTI_CH is not set ++# CONFIG_ALPHA_CABRIOLET is not set ++# CONFIG_ALPHA_DP264 is not set ++# CONFIG_ALPHA_EB164 is not set ++# CONFIG_ALPHA_EB64P_CH is not set ++# CONFIG_ALPHA_EB66 is not set ++# CONFIG_ALPHA_EB66P is not set ++# CONFIG_ALPHA_EIGER is not set ++# CONFIG_ALPHA_JENSEN is not set ++# CONFIG_ALPHA_LX164 is not set ++# CONFIG_ALPHA_LYNX is not set ++# CONFIG_ALPHA_MARVEL is not set ++# CONFIG_ALPHA_MIATA is not set ++# CONFIG_ALPHA_MIKASA is not set ++# CONFIG_ALPHA_NAUTILUS is not set ++# CONFIG_ALPHA_NONAME_CH is not set ++# CONFIG_ALPHA_NORITAKE is not set ++# CONFIG_ALPHA_PC164 is not set ++# CONFIG_ALPHA_P2K is not set ++# CONFIG_ALPHA_RAWHIDE is not set ++# CONFIG_ALPHA_RUFFIAN is not set ++# CONFIG_ALPHA_RX164 is not set ++# CONFIG_ALPHA_SX164 is not set ++# CONFIG_ALPHA_SABLE is not set ++# CONFIG_ALPHA_SHARK is not set ++# CONFIG_ALPHA_TAKARA is not set ++# CONFIG_ALPHA_TITAN is not set ++# CONFIG_ALPHA_WILDFIRE is not set ++CONFIG_ISA=y ++CONFIG_ISA_DMA_API=y ++CONFIG_PCI=y ++CONFIG_PCI_DOMAINS=y ++CONFIG_ALPHA_CORE_AGP=y ++CONFIG_GENERIC_HWEIGHT=y ++CONFIG_ALPHA_BROKEN_IRQ_MASK=y ++CONFIG_VGA_HOSE=y ++CONFIG_EISA=y ++CONFIG_ARCH_MAY_HAVE_PC_FDC=y ++CONFIG_SMP=y ++CONFIG_HAVE_DEC_LOCK=y ++CONFIG_NR_CPUS=32 ++CONFIG_BIG_TSUNAMI=y ++# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set ++CONFIG_SELECT_MEMORY_MODEL=y ++CONFIG_FLATMEM_MANUAL=y ++# CONFIG_DISCONTIGMEM_MANUAL is not set ++# CONFIG_SPARSEMEM_MANUAL is not set ++CONFIG_FLATMEM=y ++CONFIG_FLAT_NODE_MEM_MAP=y ++# CONFIG_SPARSEMEM_STATIC is not set ++CONFIG_SPLIT_PTLOCK_CPUS=4 ++CONFIG_RESOURCES_64BIT=y ++CONFIG_ZONE_DMA_FLAG=1 ++CONFIG_VERBOSE_MCHECK=y ++CONFIG_VERBOSE_MCHECK_ON=1 ++#
Re: [m5-dev] Test Repository
On Jun 7, 2008, at 2:09 PM, Steve Reinhardt wrote: My biggest worry about 3-6 months is that we often have fixes that are important and more recent than 3-6 months. Beta 5 is barely three months old and has at least two important patches, right? I was just going to use that same evidence to argue the opposite... the fact that beta5 is 3 months old and we're still finding significant bugs (including the assertion violation that Sujay posted about yesterday, which coincidentally Brad had just run into as well) says to me that we don't want to consider anything as stable until it's been through at least 3 months of availability. To jump in here, the thing is we're not finding these bugs. Saying there needs to be 3 months of testing before we release something marked stable only works if its likely that the people running the bleeding edge are will find and fix bugs before they end up in changes encompassed by the stable tag. Other users found all these cache bugs, we didn't. I personally use the most basic memory hierarchy, it takes someone coming around and deciding that they want to look at configure Z that no one has ever tried before that exposes the problem. If that only happens to revisions that are marked stable its not clear that waiting 3 months helps at all. There are also in-tree branches that can be maintained which are essentially special uses of tags. Perhaps we should learn how those work, but I don't want to maintain a separate stable version. Seems like the big thing is that we want to separate bug fixes to the stable rev from new features/enhancements that haven't been widely tested. One solution is along the lines of what you suggested... maybe we maintain the bleeding edge version as a public mq patch list, and the stable version is just what's fully committed to the repo. Bug fix patches can then bypass new-feature patches to get into the stable version more quickly. That's ok, but the issue here is that merging patches really is an ugly business. One thing we'd have to emphasize internally is that pushing to the public patch list should still be done only when you have the same level of confidence that you currently should have before pushing to the central repo. Another concern I have is that I haven't used multiple mq patchsets much... if I have this public patchset because I'm on the bleeding edge, plus maybe some internal company shared patchset for the stuff I'm working on with colleagues, plus my own patches for what I'm currently working on, how cumbersome does that get? It's not bad, patch sets can just be directories under .hg/patches. So you can have stable, internal, and mine. Maybe we should open this part of discussion to m5-users. Explain that we don't have tons of time to maintain old versions, and find out how many people would track the current revs. If we narrow it down to a couple of concrete options and can't decide among them, then asking m5-users sounds fine. I'd rather not move a very general discussion over there though. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] HG: Add compiled hg revision and date to the standard M5 output
I'm not really concerned if it catches all the exceptions. I guess I would rather have it say it's unknown, instead raising an exception that doesn't really matter all that much. Ali On Jun 7, 2008, at 4:19 PM, nathan binkert wrote: How about this? (I didn't actually run it). I just worry that you catch all exceptions. There might be some sort of bug lurking in there that we want to know about. def hgInfo(self, target, source, env): def gen_file(target, rev=Unknown, node=Unknown, date=Unknown): hg_stats = file(target, 'w') print hg_stats, 'const char *hgRev = %s:%s;' % (rev, node) print hg_stats, 'const char *hgDate = %s;' % date hg_stats.close() target = str(target[0]) scons_dir = eval(str(source[0])) if not exists(scons_dir) or not isdir(scons_dir) or \ not exists(join(scons_dir, .hg)): gen_file(target) return try: import mercurial except ImportError: gen_file(target) return import mercurial.demandimport, mercurial.hg, mercurial.ui import mercurial.util, mercurial.node repo = mercurial.hg.repository(mercurial.ui.ui(), scons_dir) rev = mercurial.node.nullrev + repo.changelog.count() changenode = repo.changelog.node(rev) changes = repo.changelog.read(changenode) date = mercurial.util.datestr(changes[2]) gen_file(target, rev, mercurial.node.hex(changenode), date) mercurial.demandimport.disable() ___ 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] Test Repository
On Jun 7, 2008, at 5:52 PM, Ali Saidi wrote: On Jun 7, 2008, at 5:44 PM, nathan binkert wrote: Aren't these statements contradictory? If you have the patch sets under separate subdirs, can they come from different repos? Would you still have to manually merge the series file? I don't totally blame Gabe for having the willies about this. Yeah, it sorta gives me the willies too. Maybe what I suggest below could be better. They aren't. Merging patches in an ugly business that I think we should avoid. MQ is pretty flexible about patches and subdirectoires so you can have various directories under .hg/patches each of which is a hg repository, however hg qcommit and the like won't work. Yes you would have to manually update the series file with all the patches from each directory. In reality if we went down this path --- which I'm not endorsing at all --- I would be tempted to hack MQ so that the root series file could just be pointers to other series files. My main fear is that if all we offer as a default download is the tip, then if something broken gets in there and someone downloads m5 for the first time and it doesn't work, that's not good. Maybe Nate's idea of automatically advancing the stable pointer once we've run the fullest possible set of regressions is the right way to go, and we can try harder to make sure that when we see some configuration break we create a regression test for it. I think this, combined with something like a testing repository which has regular regressions run as well and is maybe similar to the mercurial crew repository. Basically, people are allowed to push more speculative things to the testing repository, and they'll get regressions run on that repository. (If we do some sort of automatic bisect, that would be awesome) If the testing repository gets totally whacked, it's easy to blow it away and just ask people to re-add stuff. Maybe this should be done with a mq repository instead of a normal repository. (Is this what you had in mind steve?) This way, when people commit stuff, they can remove it from the queue and not figure out how to merge it. We could also alternatively come up with some way to just have a directory of mq trees that can be individually maintained by people, and have the regression framework automatically do a separate regression on all of the mq trees that are there. I just look a quick look at the hg webserver code. There isn't a direct way to download a revision. We could add one, or we could go back to my original suggestion that we have m5-stable and m5-dev and just pull to m5-stable at whatever interval. I even wrote a script to spam m5-dev if more than XXX days had gone by without an update to m5- stable. Just like Nate says we can then whack m5-dev if something goes awry and reclone from m5-stable. Another reason to have separate repos instead of just tagging if we're going to do stuff at this rate is that each retagging generates a new changeset. Pulling from a repo named x to a repo named y doesn't. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
I quickly scanned the SCons documentation and couldn't find anything built in, but clearly the kernel does it so it can be done. Ali On Jun 9, 2008, at 5:48 AM, Gabe Black wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. 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
Re: [m5-dev] incremental linking
I've done some reading online and it doesn't appear that incremental linking will cut down on the link time much at all. Doing it in smaller chunks doesn't help if all the symbols end up being exported at the end. The two ways to speed it up are to (a) not include any debugging information (remove the -g flag) or (b) build various pieces as shared libraries and link them dynamically at runtime. (a) isn't probably useful for your purposes and (b) increases the difficultly of debugging the code substantially as well as requires various pieces of the simulator to be completely independent. Either way I doubt it's worth the effort. Ali On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
One thing to try maybe is Intel CC. Perhaps their linker is faster? or do they use ld? You're probably running into a I/O limitation on your laptop not a CPU problem. Ali On Jun 9, 2008, at 2:02 PM, nathan binkert wrote: Yeah, that makes sense. We don't really have subsystems with local symbols. That said, is it faster to incremental link strip and then finish the link? I'm just curious if there are any symbols that we can automatically strip. Then again, I build debug most of the time and you wouldn't want to strip that, so... Nate On Mon, Jun 9, 2008 at 10:50 AM, Ali Saidi [EMAIL PROTECTED] wrote: I've done some reading online and it doesn't appear that incremental linking will cut down on the link time much at all. Doing it in smaller chunks doesn't help if all the symbols end up being exported at the end. The two ways to speed it up are to (a) not include any debugging information (remove the -g flag) or (b) build various pieces as shared libraries and link them dynamically at runtime. (a) isn't probably useful for your purposes and (b) increases the difficultly of debugging the code substantially as well as requires various pieces of the simulator to be completely independent. Either way I doubt it's worth the effort. Ali On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. 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 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] Repository open for business
If we wait 1 week (the 18th), it will be exactly 2 years from when we said we would have 2.0 done and the repository released at the M5 tutorial at ISCA 2006. :) Ali On Jun 11, 2008, at 7:38 PM, nathan binkert wrote: Unless anyone has an objection, I think the new repository is open for business. Please start committing. I figure we'll do our own things for the next day or two just to allow a little bit of time to check for bugs. We'll open it up to the public either Friday or Monday. Sound good? Nate ___ 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] Repository open for business
The hgrc for the repo didn't exist/wasn't copied from the old directory. I've added it and I imagine the e-mails will now be sent. Ali On Jun 12, 2008, at 2:25 AM, Gabe Black wrote: I just did a big push but there was no email... Also, I made sure everything compiled and ran all the quick regressions except for Alpha FS where I'd have to download disk images and all that, but it's probably a good idea to wait until the full regressions run successfully before everybody starts downloading it. Gabe nathan binkert wrote: Unless anyone has an objection, I think the new repository is open for business. Please start committing. I figure we'll do our own things for the next day or two just to allow a little bit of time to check for bugs. We'll open it up to the public either Friday or Monday. Sound good? Nate ___ 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] Repository open for business
I did a little bit of digging and you can specify a taged version of the repo like this: http://site/repo/archive/tag.tar.bz2 and it will download version of the repo. Ali On Jun 12, 2008, at 10:06 AM, Ali Saidi wrote: The hgrc for the repo didn't exist/wasn't copied from the old directory. I've added it and I imagine the e-mails will now be sent. Ali On Jun 12, 2008, at 2:25 AM, Gabe Black wrote: I just did a big push but there was no email... Also, I made sure everything compiled and ran all the quick regressions except for Alpha FS where I'd have to download disk images and all that, but it's probably a good idea to wait until the full regressions run successfully before everybody starts downloading it. Gabe nathan binkert wrote: Unless anyone has an objection, I think the new repository is open for business. Please start committing. I figure we'll do our own things for the next day or two just to allow a little bit of time to check for bugs. We'll open it up to the public either Friday or Monday. Sound good? Nate ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] host bridge device
Looking at this code it seems like the easiest thing is to make sure
that dmi_get_year(DMI_BIOS_DATE) = 2001.Do you have a DMI table? If
you set the BIOS date 2001 the function could be skipped. It's just
checking if it some device exists that makes it think this is actually
PCI that it's reading and it's not off in the weeds.
I don't particularly like the idea of faking a host bridge or a VGA
adapter, because at some point Linux is going to come back and try to
configure those devices you attempted to Fake. Since we don't really
care to have a host bridge or a VGA adapter at this point that seems
like a waste of time. While it's likely that we will have something
that Intel makes I don't think we want to make it have to be bus 0, id
0 for this to work.
So in summary:
1. Update the DMI table so the bios date is 2001.
2. If that fails it's pretty safe to use a M5 SkipFuncEvent to just
skip the function.
Ali
On Jun 13, 2008, at 3:32 AM, Gabe Black wrote:
The code following the comment in my original email is below.
Basically,
it looks like the kernel reads some registers out of the config
space of
bus 0 dev 0 function 0-0x100 and sees if they match certain values.
I'd
imagine that wouldn't be very hard to do but I don't have any
experience
with the PCI stuff. Is there something I can look at as an example?
How
do I put something at a particular bus/dev/function?
Gabe
static int __init pci_sanity_check(struct pci_raw_ops *o)
{
u32 x = 0;
int devfn;
if (pci_probe PCI_NO_CHECKS)
return 1;
/* Assume Type 1 works for newer systems.
This handles machines that don't have anything on PCI Bus 0. */
if (dmi_get_year(DMI_BIOS_DATE) = 2001)
return 1;
for (devfn = 0; devfn 0x100; devfn++) {
if (o-read(0, 0, devfn, PCI_CLASS_DEVICE, 2, x))
continue;
if (x == PCI_CLASS_BRIDGE_HOST || x == PCI_CLASS_DISPLAY_VGA)
return 1;
if (o-read(0, 0, devfn, PCI_VENDOR_ID, 2, x))
continue;
if (x == PCI_VENDOR_ID_INTEL || x == PCI_VENDOR_ID_COMPAQ)
return 1;
}
DBG(KERN_WARNING PCI: Sanity check failed\n);
return 0;
}
nathan binkert wrote:
So this would be the PCI bus support in the north bridge for
instance?
Should I just arbitrarily pick a chipset and implement that, or is
there
something more generic?
I think that there's really only one interface for this that really
matters. On alpha, there were lots of north bridge interfaces, but
on
x86, they still basically use the same one. Some chipsets have
extensions (for secondary bridges and such), but we don't need to use
those.
I agree with Ali on the look at the kernel part.
Nate
___
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] namespaces for python SimObjects
On Jun 13, 2008, at 11:48 AM, nathan binkert wrote: Are instances of class objects uniquely identifiable and usable as keys? Only if they provide a __hash__ function, but in theory it should be possible. If so, you could use the class as a key using the same mechanism instead of the string name with Param.blah. So then you use class Foo to look up a param description rather than actually doing something fancy with Foo itself. I don't quite follow the subtleties of what you guys are talking about so I'm not sure if that helps. The problem is that we can now do this: class Foo(SimObject): bar = Param.Bar() class Bar(SimObject): foo = Param.Foo() Because of tricks we did with attribute lookup with Param, the parameter type isn't looked up until the objects are all constructed. In your case: class Foo(SimObject): bar = Param(Bar, ) class Bar(SimObject): foo = Param(Foo, ) The bar parameter would get an error because Bar is not yet defined. It's not particularly easy to get around this. Python 3.0 and the new way they do metaclasses can help you solve the problem, but unfortunately, that's not going to be mainstream for a while Where do we have circular references? You can't construct objects with circular references in C++, so why do we need it in Python? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH 0 of 3] Sort out the name console
On Jun 16, 2008, at 1:01 PM, Nathan Binkert wrote: I mentioned in a e-mail last night that I'd like to rename the various things that are called console so that the names are not as ambiguous. The following renames apply: SimConsole - Terminal AlphaConsole - AlphaBackdoor MipsConsole - MipsBackdoor Everyone OK with this? I'm fine with it, but I think we should only do it once (more). So we should get the names right this time. If you commit the patch, please also update the documentation on the website. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Port confusion
On Jun 20, 2008, at 10:06 PM, Steve Reinhardt wrote:
/** Return a virtual port. If no thread context is specified then
a static
* port is returned. Otherwise a port is created and returned. It
must be
* deleted by deleteVirtPort(). */
VirtualPort*
SimpleThread::getVirtPort(ThreadContext *src_tc)
{
if (!src_tc)
return virtPort;
VirtualPort *vp = new VirtualPort(tc-vport, src_tc);
connectToMemFunc(vp);
return vp;
}
Note that (1) the declaration gives a default value of NULL for src_tc
and (2) getVirtPort is only ever called with no arguments (getting the
NULL default) or with this == src_tc, e.g., tc-getVirtPort(tc). So
the presence of src_tc is effectively just a boolean, as the comment
implies. Can anyone explain why this is necessary?
I believe the thinking was something like this, although the
implementation doesn't appear to reflect that. If you just need a
virtual port for a short time and don't plan to cache it then the
fastest thing to do is just return you a copy of a statically
allocated virtual port to do functional accesses on. On the other hand
if the requesting object planned to keep the pointer around for a
while in the interim a cpu switchover could occur in which case your
virtual port might not be pointing to where it should be so you needed
a dynamically allocated one. This doesn't really appear to be the case
as the dynamically allocated ports are never updated, but I think that
was the plan.
Ali
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression --scratch all
00:19:51 [saidi:zizzer /z/m5/regression/poolfs/m5] cat build/ALPHA_FS/ tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple- atomic/stderr warn: kernel located at: /dist/m5/system/binaries/vmlinux panic: ListenSocket(listen): listen() failed! @ cycle 0 [listen:build/ALPHA_FS/base/socket.cc, line 91] Program aborted at cycle 0 On Jun 22, 2008, at 3:03 AM, Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple- timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple- timing passed. scons: *** [build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/ linux/twosys-tsunami-simple-atomic/stdout] Error 134 scons: *** [build/MIPS_SE/mem/cache/cache.fo] Error 1 * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/ tsunami-simple-timing-dual passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple- atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple- timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3- timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple- timing passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/simple- timing passed. * build/SPARC_SE/tests/fast/long/50.vortex/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/long/70.twolf/sparc/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/simple- timing passed. * build/SPARC_SE/tests/fast/long/50.vortex/sparc/linux/simple- timing passed. * build/SPARC_SE/tests/fast/long/10.mcf/sparc/linux/simple- atomic passed. * build/SPARC_SE/tests/fast/long/70.twolf/sparc/linux/simple- timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/long/10.mcf/sparc/linux/simple- timing passed. * build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple- atomic passed. * build/X86_SE/tests/fast/long/70.twolf/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/long/10.mcf/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/o3-timing passed. * build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/simple- atomic passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/simple- timing passed. * build/ALPHA_SE/tests/fast/long/40.perlbmk/alpha/tru64/simple- timing passed. * build/SPARC_FS/tests/fast/long/80.solaris-boot/sparc/solaris/ t1000-simple-atomic passed. * build/SPARC_SE/tests/fast/long/00.gzip/sparc/linux/simple- timing passed. Reading the dictionary files: * * build/X86_SE/tests/fast/long/20.parser/x86/linux/simple-atomic FAILED! * build/X86_SE/tests/fast/long/00.gzip/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/long/30.eon/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/long/00.gzip/alpha/tru64/o3-timing passed. * build/X86_SE/tests/fast/long/60.bzip2/x86/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/o3-timing passed.
[m5-dev] m5-stable: Checkpoinging/SWIG: Undo part of changeset 5464 since...
changeset ebec0a848220 in /z/repo/m5-stable
details: http://repo.m5sim.org/m5-stable?cmd=changeset;node=ebec0a848220
summary: Checkpoinging/SWIG: Undo part of changeset 5464 since it broke
checkpointing.
diffstat:
1 file changed, 1 deletion(-)
src/python/swig/event.i |1 -
diffs (14 lines):
diff -r 47c5168d092c -r ebec0a848220 src/python/swig/event.i
--- a/src/python/swig/event.i Sat Jun 14 21:51:08 2008 -0700
+++ b/src/python/swig/event.i Tue Jun 24 15:48:45 2008 -0400
@@ -44,8 +44,8 @@
void create(PyObject *object, Tick when);
-class CountedDrainEvent
-{
+class Event;
+class CountedDrainEvent : public Event {
public:
void setCount(int _count);
};
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] m5: 2 new changesets
This changeset creates an extraordinarily large memory leak. Every
time getVirtPort(tc) is called a peer seems to be created that is
never deleted. This is particularly problematic since CopyString*()
uses getVirtPort(tc) and so within a minute of executing a kernel with
a lot of dprintk()s M5 uses about 2GB of memory.
Ali
On Jun 21, 2008, at 1:19 AM, Steve Reinhardt wrote:
changeset 94a7bb476fca in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=94a7bb476fca
summary: Generate more useful error messages for unconnected ports.
changeset 88f1e9295945 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=88f1e9295945
summary: Make bus address conflict error more informative
diffstat:
8 files changed, 11 insertions(+), 11 deletions(-)
src/cpu/o3/fetch.hh |1 -
src/cpu/o3/lsq.hh |1 -
src/mem/bus.cc |1 -
src/mem/cache/cache_impl.hh |4 ++--
src/mem/mem_object.cc |1 -
src/mem/mem_object.hh |5 ++---
src/mem/port.cc |7 +++
src/mem/port.hh |2 --
diffs (truncated from 410 to 300 lines):
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/fetch.hh
--- a/src/cpu/o3/fetch.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/fetch.hh Sat Jun 21 01:06:27 2008 -0400
@@ -80,8 +80,8 @@ class DefaultFetch
public:
/** Default constructor. */
-IcachePort(DefaultFetchImpl *_fetch)
-: Port(_fetch-name() + -iport), fetch(_fetch)
+IcachePort(DefaultFetchImpl *_fetch, O3CPU *_cpu)
+: Port(_fetch-name() + -iport, _cpu), fetch(_fetch)
{ }
bool snoopRangeSent;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/fetch_impl.hh
--- a/src/cpu/o3/fetch_impl.hhWed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/fetch_impl.hhSat Jun 21 01:06:27 2008 -0400
@@ -167,7 +167,7 @@ DefaultFetchImpl::DefaultFetch(O3CPU *
instSize = sizeof(TheISA::MachInst);
// Name is finally available, so create the port.
-icachePort = new IcachePort(this);
+icachePort = new IcachePort(this, cpu);
icachePort-snoopRangeSent = false;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/lsq.hh
--- a/src/cpu/o3/lsq.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/lsq.hh Sat Jun 21 01:06:27 2008 -0400
@@ -296,8 +296,8 @@ class LSQ {
public:
/** Default constructor. */
-DcachePort(LSQ *_lsq)
-: Port(_lsq-name() + -dport), lsq(_lsq)
+DcachePort(LSQ *_lsq, O3CPU *_cpu)
+: Port(_lsq-name() + -dport, _cpu), lsq(_lsq)
{ }
bool snoopRangeSent;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/lsq_impl.hh
--- a/src/cpu/o3/lsq_impl.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/lsq_impl.hh Sat Jun 21 01:06:27 2008 -0400
@@ -112,7 +112,7 @@ LSQImpl::DcachePort::recvRetry()
template class Impl
LSQImpl::LSQ(O3CPU *cpu_ptr, IEW *iew_ptr, Params *params)
-: cpu(cpu_ptr), iewStage(iew_ptr), dcachePort(this),
+: cpu(cpu_ptr), iewStage(iew_ptr), dcachePort(this, cpu_ptr),
LQEntries(params-LQEntries),
SQEntries(params-SQEntries),
numThreads(params-numberOfThreads),
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/thread_context_impl.hh
--- a/src/cpu/o3/thread_context_impl.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/thread_context_impl.hh Sat Jun 21 01:06:27 2008 -0400
@@ -103,7 +103,6 @@ O3ThreadContextImpl::delVirtPort(Virtu
O3ThreadContextImpl::delVirtPort(VirtualPort *vp)
{
if (vp != thread-getVirtPort()) {
-vp-removeConn();
delete vp;
}
}
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/ozone/cpu_impl.hh
--- a/src/cpu/ozone/cpu_impl.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/ozone/cpu_impl.hh Sat Jun 21 01:06:27 2008 -0400
@@ -747,7 +747,6 @@ void
void
OzoneCPUImpl::OzoneTC::delVirtPort(VirtualPort *vp)
{
-vp-removeConn();
delete vp;
}
#endif
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/simple_thread.cc
--- a/src/cpu/simple_thread.ccWed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/simple_thread.ccSat Jun 21 01:06:27 2008 -0400
@@ -302,7 +302,6 @@ SimpleThread::delVirtPort(VirtualPort *v
SimpleThread::delVirtPort(VirtualPort *vp)
{
if (vp != virtPort) {
-vp-removeConn();
delete vp;
}
}
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/thread_state.cc
--- a/src/cpu/thread_state.cc Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/thread_state.cc Sat Jun 21 01:06:27 2008 -0400
@@ -126,7 +126,7 @@ ThreadState::connectPhysPort()
// already existed. Fix this memory leak once the bus port IDs
// for functional ports is resolved.
if (physPort)
-physPort-removeConn();
+physPort-disconnectFromPeer();
else
physPort = new FunctionalPort(csprintf(%s-%d-funcport,
Re: [m5-dev] m5: 2 new changesets
I thought about that and got rid of the ones in CopyString*().
However, without passing the tc object and creating a new port the
getfile (m5 op that stucks in the config file) fails to work
correctly. There must be something more going on there, but I couldn't
figure out what was happening.
Ali
On Jun 27, 2008, at 7:37 PM, Steve Reinhardt wrote:
Bummer... sorry about that. I think it was originally OK but in the
process of working around the issue with N:1 functional ports (recall
our earlier discussion on this) I backed off on deleting ports
aggressively and ended up with this leak.
That said, is there any reason that CopyString*() really needs to
dynamically allocate a new port? I'd guess that changing
getVirtPort(tc) to getVirtPort() and getting rid of the
tc-delVirtPort(tc) call would avoid the problem as well.
If we got rid of *all* the getVirtPort(tc) calls then I could probably
uncomment the disconnectFromPeer() call in Port::setPeer() and that
would go a long way toward fixing the actual memory leak.
Steve
On Fri, Jun 27, 2008 at 3:50 PM, Ali Saidi [EMAIL PROTECTED] wrote:
This changeset creates an extraordinarily large memory leak. Every
time getVirtPort(tc) is called a peer seems to be created that is
never deleted. This is particularly problematic since CopyString*()
uses getVirtPort(tc) and so within a minute of executing a kernel
with
a lot of dprintk()s M5 uses about 2GB of memory.
Ali
On Jun 21, 2008, at 1:19 AM, Steve Reinhardt wrote:
changeset 94a7bb476fca in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=94a7bb476fca
summary: Generate more useful error messages for unconnected ports.
changeset 88f1e9295945 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=88f1e9295945
summary: Make bus address conflict error more informative
diffstat:
8 files changed, 11 insertions(+), 11 deletions(-)
src/cpu/o3/fetch.hh |1 -
src/cpu/o3/lsq.hh |1 -
src/mem/bus.cc |1 -
src/mem/cache/cache_impl.hh |4 ++--
src/mem/mem_object.cc |1 -
src/mem/mem_object.hh |5 ++---
src/mem/port.cc |7 +++
src/mem/port.hh |2 --
diffs (truncated from 410 to 300 lines):
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/fetch.hh
--- a/src/cpu/o3/fetch.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/fetch.hh Sat Jun 21 01:06:27 2008 -0400
@@ -80,8 +80,8 @@ class DefaultFetch
public:
/** Default constructor. */
-IcachePort(DefaultFetchImpl *_fetch)
-: Port(_fetch-name() + -iport), fetch(_fetch)
+IcachePort(DefaultFetchImpl *_fetch, O3CPU *_cpu)
+: Port(_fetch-name() + -iport, _cpu), fetch(_fetch)
{ }
bool snoopRangeSent;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/fetch_impl.hh
--- a/src/cpu/o3/fetch_impl.hhWed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/fetch_impl.hhSat Jun 21 01:06:27 2008 -0400
@@ -167,7 +167,7 @@ DefaultFetchImpl::DefaultFetch(O3CPU *
instSize = sizeof(TheISA::MachInst);
// Name is finally available, so create the port.
-icachePort = new IcachePort(this);
+icachePort = new IcachePort(this, cpu);
icachePort-snoopRangeSent = false;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/lsq.hh
--- a/src/cpu/o3/lsq.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/lsq.hh Sat Jun 21 01:06:27 2008 -0400
@@ -296,8 +296,8 @@ class LSQ {
public:
/** Default constructor. */
-DcachePort(LSQ *_lsq)
-: Port(_lsq-name() + -dport), lsq(_lsq)
+DcachePort(LSQ *_lsq, O3CPU *_cpu)
+: Port(_lsq-name() + -dport, _cpu), lsq(_lsq)
{ }
bool snoopRangeSent;
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/lsq_impl.hh
--- a/src/cpu/o3/lsq_impl.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/o3/lsq_impl.hh Sat Jun 21 01:06:27 2008 -0400
@@ -112,7 +112,7 @@ LSQImpl::DcachePort::recvRetry()
template class Impl
LSQImpl::LSQ(O3CPU *cpu_ptr, IEW *iew_ptr, Params *params)
-: cpu(cpu_ptr), iewStage(iew_ptr), dcachePort(this),
+: cpu(cpu_ptr), iewStage(iew_ptr), dcachePort(this, cpu_ptr),
LQEntries(params-LQEntries),
SQEntries(params-SQEntries),
numThreads(params-numberOfThreads),
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/o3/
thread_context_impl.hh
--- a/src/cpu/o3/thread_context_impl.hh Wed Jun 18 12:07:15
2008 -0700
+++ b/src/cpu/o3/thread_context_impl.hh Sat Jun 21 01:06:27
2008 -0400
@@ -103,7 +103,6 @@ O3ThreadContextImpl::delVirtPort(Virtu
O3ThreadContextImpl::delVirtPort(VirtualPort *vp)
{
if (vp != thread-getVirtPort()) {
-vp-removeConn();
delete vp;
}
}
diff -r c8571e8ce7b6 -r 88f1e9295945 src/cpu/ozone/cpu_impl.hh
--- a/src/cpu/ozone/cpu_impl.hh Wed Jun 18 12:07:15 2008 -0700
+++ b/src/cpu/ozone/cpu_impl.hh Sat
Re: [m5-dev] Parallel M5
I vote for (1) until it can be shown that it matters. A single pointer doesn't seem like a big deal, especially since most of the things we create and destroy frequently aren't SimObjects but other classes. Ali On Jun 29, 2008, at 12:23 PM, nathan binkert wrote: I'm nearly done with the first step of getting parallel M5 working. -- Add an EventQueue pointer to every SimObject and add schedule()/deschedule()/reschedule() functions to the Base SimObject to use that event queue pointer. -- Change all calls to event scheduling to use that EventQueue pointer. -- Remove the schedule/deschedule/reschedule functions on the Event object. Now, you must create an event and schedule it on an event queue. An example of this is something like this: old: new LinkDelayEvent(this, packet, curTick + linkDelay); new: Event *event = new LinkDelayEvent(this, packet); this-schedule(event, curTick + linkDelay); I'd like to remove the queue pointer from the event object since there is only one use case where you've scheduled an event and you don't know which queue it's on if you want to de/reschedule it. It's for repeat events like the SimLoopExitEvent. Here are the options: 1) Leave the queue pointer in the object 2) Pass the queue pointer as a parameter to the process() function 3) Record the queue pointer in just those objects that require it 4) Create a new flag to the event called AutoRepeat, create a virtual function that can be called to determine the repeat interval, and add support for repeat in the event queue 5) Create a thread local global variable called currentEventQueue. (I hate this idea) I go back and forth as to the right thing to do. I'd really like to avoid the queue pointer in all objects so we can keep events small, but I guess it can easily be argued that I shouldn't keep that optimization unless I know that it will pay off, but the only way to know if it will pay off is to just do it. I also basically hate #5 and it's on the bottom of my list. One issue is that because of the committed instruction queue, there can be more than one event queue in a given thread. Anyone have any opinions? BTW: I'll write up a Parallelizing M5 wiki page in the next day or so that enumerates all of my plans. Nate ___ 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] [PATCH] After a checkpoint (and thus a stats reset), the not_idle_fraction/notIdleFraction statistic is really wrong
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214782927 14400
# Node ID ada5724fbc53640aa6b85ba82e5a43d2e7a67092
# Parent d9de38fba64c204f5eb5ea87adb9b9c0c9e9c1c6
After a checkpoint (and thus a stats reset), the
not_idle_fraction/notIdleFraction statistic is really wrong.
The notIdleFraction statistic isn't updated when the statistics reset, probably
because the cpu Status information
was pulled into the atomic and timing cpus. This changeset pulls Status back
into the BaseSimpleCPU object. Anyone
care to comment on the odd naming of the Status instance? It shouldn't just be
status because that is confusing
with Port::Status, but _status seems a bit strage too.
diff --git a/src/cpu/simple/atomic.cc b/src/cpu/simple/atomic.cc
--- a/src/cpu/simple/atomic.cc
+++ b/src/cpu/simple/atomic.cc
@@ -176,8 +176,6 @@ AtomicSimpleCPU::serialize(ostream os)
{
SimObject::State so_state = SimObject::getState();
SERIALIZE_ENUM(so_state);
-Status _status = status();
-SERIALIZE_ENUM(_status);
BaseSimpleCPU::serialize(os);
nameOut(os, csprintf(%s.tickEvent, name()));
tickEvent.serialize(os);
@@ -188,7 +186,6 @@ AtomicSimpleCPU::unserialize(Checkpoint
{
SimObject::State so_state;
UNSERIALIZE_ENUM(so_state);
-UNSERIALIZE_ENUM(_status);
BaseSimpleCPU::unserialize(cp, section);
tickEvent.unserialize(cp, csprintf(%s.tickEvent, section));
}
@@ -213,7 +210,7 @@ void
void
AtomicSimpleCPU::switchOut()
{
-assert(status() == Running || status() == Idle);
+assert(_status == Running || _status == Idle);
_status = SwitchedOut;
tickEvent.squash();
diff --git a/src/cpu/simple/atomic.hh b/src/cpu/simple/atomic.hh
--- a/src/cpu/simple/atomic.hh
+++ b/src/cpu/simple/atomic.hh
@@ -47,19 +47,6 @@ class AtomicSimpleCPU : public BaseSimpl
virtual ~AtomicSimpleCPU();
virtual void init();
-
- public:
-//
-enum Status {
-Running,
-Idle,
-SwitchedOut
-};
-
- protected:
-Status _status;
-
-Status status() const { return _status; }
private:
diff --git a/src/cpu/simple/base.cc b/src/cpu/simple/base.cc
--- a/src/cpu/simple/base.cc
+++ b/src/cpu/simple/base.cc
@@ -174,12 +174,13 @@ BaseSimpleCPU::resetStats()
BaseSimpleCPU::resetStats()
{
//startNumInst = numInst;
-// notIdleFraction = (_status != Idle);
+ notIdleFraction = (_status != Idle);
}
void
BaseSimpleCPU::serialize(ostream os)
{
+SERIALIZE_ENUM(_status);
BaseCPU::serialize(os);
//SERIALIZE_SCALAR(inst);
nameOut(os, csprintf(%s.xc.0, name()));
@@ -189,6 +190,7 @@ void
void
BaseSimpleCPU::unserialize(Checkpoint *cp, const string section)
{
+UNSERIALIZE_ENUM(_status);
BaseCPU::unserialize(cp, section);
//UNSERIALIZE_SCALAR(inst);
thread-unserialize(cp, csprintf(%s.xc.0, section));
diff --git a/src/cpu/simple/base.hh b/src/cpu/simple/base.hh
--- a/src/cpu/simple/base.hh
+++ b/src/cpu/simple/base.hh
@@ -128,6 +128,20 @@ class BaseSimpleCPU : public BaseCPU
ThreadContext *tc;
protected:
int cpuId;
+
+enum Status {
+Idle,
+Running,
+IcacheRetry,
+IcacheWaitResponse,
+IcacheWaitSwitch,
+DcacheRetry,
+DcacheWaitResponse,
+DcacheWaitSwitch,
+SwitchedOut
+};
+
+Status _status;
public:
diff --git a/src/cpu/simple/timing.cc b/src/cpu/simple/timing.cc
--- a/src/cpu/simple/timing.cc
+++ b/src/cpu/simple/timing.cc
@@ -145,7 +145,7 @@ TimingSimpleCPU::drain(Event *drain_even
{
// TimingSimpleCPU is ready to drain if it's not waiting for
// an access to complete.
-if (status() == Idle || status() == Running || status() == SwitchedOut) {
+if (_status == Idle || _status == Running || _status == SwitchedOut) {
changeState(SimObject::Drained);
return 0;
} else {
@@ -179,7 +179,7 @@ void
void
TimingSimpleCPU::switchOut()
{
-assert(status() == Running || status() == Idle);
+assert(_status == Running || _status == Idle);
_status = SwitchedOut;
numCycles += tickToCycles(curTick - previousTick);
diff --git a/src/cpu/simple/timing.hh b/src/cpu/simple/timing.hh
--- a/src/cpu/simple/timing.hh
+++ b/src/cpu/simple/timing.hh
@@ -46,24 +46,6 @@ class TimingSimpleCPU : public BaseSimpl
virtual void init();
public:
-//
-enum Status {
-Idle,
-Running,
-IcacheRetry,
-IcacheWaitResponse,
-IcacheWaitSwitch,
-DcacheRetry,
-DcacheWaitResponse,
-DcacheWaitSwitch,
-SwitchedOut
-};
-
- protected:
-Status _status;
-
-Status status() const { return _status; }
-
Event *drainEvent;
private:
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] [PATCH 0 of 2] Fix cached virtPort use cached copy everywhere
___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] [PATCH 1 of 2] Make the cached virtPort have a thread context so it can do everything that a newly created one can
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214782929 14400
# Node ID 363df5ea90da6ff8283c0f3d9c29a4e26efbe4a5
# Parent 8f98b8f28e474fc98d16f5e3973b01a5f2b0a6ff
Make the cached virtPort have a thread context so it can do everything that a
newly created one can.
diff --git a/src/cpu/o3/cpu.cc b/src/cpu/o3/cpu.cc
--- a/src/cpu/o3/cpu.cc
+++ b/src/cpu/o3/cpu.cc
@@ -788,7 +788,7 @@ FullO3CPUImpl::updateMemPorts()
// Update all ThreadContext's memory ports (Functional/Virtual
// Ports)
for (int i = 0; i thread.size(); ++i)
-thread[i]-connectMemPorts();
+thread[i]-connectMemPorts(thread[i]-getTC());
}
#endif
diff --git a/src/cpu/o3/thread_context.hh b/src/cpu/o3/thread_context.hh
--- a/src/cpu/o3/thread_context.hh
+++ b/src/cpu/o3/thread_context.hh
@@ -98,7 +98,7 @@ class O3ThreadContext : public ThreadCon
void delVirtPort(VirtualPort *vp);
-virtual void connectMemPorts() { thread-connectMemPorts(); }
+virtual void connectMemPorts(ThreadContext *tc) {
thread-connectMemPorts(tc); }
#else
virtual TranslatingPort *getMemPort() { return thread-getMemPort(); }
diff --git a/src/cpu/simple/atomic.cc b/src/cpu/simple/atomic.cc
--- a/src/cpu/simple/atomic.cc
+++ b/src/cpu/simple/atomic.cc
@@ -148,7 +148,7 @@ AtomicSimpleCPU::DcachePort::setPeer(Por
#if FULL_SYSTEM
// Update the ThreadContext's memory ports (Functional/Virtual
// Ports)
-cpu-tcBase()-connectMemPorts();
+cpu-tcBase()-connectMemPorts(cpu-tcBase());
#endif
}
diff --git a/src/cpu/simple/timing.cc b/src/cpu/simple/timing.cc
--- a/src/cpu/simple/timing.cc
+++ b/src/cpu/simple/timing.cc
@@ -766,7 +766,7 @@ TimingSimpleCPU::DcachePort::setPeer(Por
#if FULL_SYSTEM
// Update the ThreadContext's memory ports (Functional/Virtual
// Ports)
-cpu-tcBase()-connectMemPorts();
+cpu-tcBase()-connectMemPorts(cpu-tcBase());
#endif
}
diff --git a/src/cpu/thread_context.hh b/src/cpu/thread_context.hh
--- a/src/cpu/thread_context.hh
+++ b/src/cpu/thread_context.hh
@@ -134,7 +134,7 @@ class ThreadContext
virtual void delVirtPort(VirtualPort *vp) = 0;
-virtual void connectMemPorts() = 0;
+virtual void connectMemPorts(ThreadContext *tc) = 0;
#else
virtual TranslatingPort *getMemPort() = 0;
@@ -325,7 +325,7 @@ class ProxyThreadContext : public Thread
void delVirtPort(VirtualPort *vp) { return actualTC-delVirtPort(vp); }
-void connectMemPorts() { actualTC-connectMemPorts(); }
+void connectMemPorts(ThreadContext *tc) { actualTC-connectMemPorts(tc); }
#else
TranslatingPort *getMemPort() { return actualTC-getMemPort(); }
diff --git a/src/cpu/thread_state.cc b/src/cpu/thread_state.cc
--- a/src/cpu/thread_state.cc
+++ b/src/cpu/thread_state.cc
@@ -113,10 +113,10 @@ ThreadState::unserialize(Checkpoint *cp,
#if FULL_SYSTEM
void
-ThreadState::connectMemPorts()
+ThreadState::connectMemPorts(ThreadContext *tc)
{
connectPhysPort();
-connectVirtPort();
+connectVirtPort(tc);
}
void
@@ -134,7 +134,7 @@ ThreadState::connectPhysPort()
}
void
-ThreadState::connectVirtPort()
+ThreadState::connectVirtPort(ThreadContext *tc)
{
// @todo: For now this disregards any older port that may have
// already existed. Fix this memory leak once the bus port IDs
@@ -143,7 +143,7 @@ ThreadState::connectVirtPort()
virtPort-disconnectFromPeer();
else
virtPort = new VirtualPort(csprintf(%s-%d-vport,
-baseCpu-name(), tid));
+baseCpu-name(), tid), tc);
connectToMemFunc(virtPort);
}
diff --git a/src/cpu/thread_state.hh b/src/cpu/thread_state.hh
--- a/src/cpu/thread_state.hh
+++ b/src/cpu/thread_state.hh
@@ -91,11 +91,11 @@ struct ThreadState {
Tick readLastSuspend() { return lastSuspend; }
#if FULL_SYSTEM
-void connectMemPorts();
+void connectMemPorts(ThreadContext *tc);
void connectPhysPort();
-void connectVirtPort();
+void connectVirtPort(ThreadContext *tc);
void dumpFuncProfile();
@@ -201,7 +201,7 @@ struct ThreadState {
FunctionalPort *physPort;
/** A functional port, outgoing only, for functional accesse to virtual
- * addresses. That doen't require execution context information */
+ * addresses. */
VirtualPort *virtPort;
#else
TranslatingPort *port;
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] [PATCH 2 of 2] Change everything to use the cached virtPort rather than created their own each time
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214783163 14400
# Node ID 1c93d818b049e51e3b86c123d3ad86a1555a467b
# Parent 363df5ea90da6ff8283c0f3d9c29a4e26efbe4a5
Change everything to use the cached virtPort rather than created their own each
time.
This appears to work, but I don't want to commit it until it gets tested a lot
more.
I haven't deleted the functionality in this patch that will come later, but one
question
is how to enforce encourage objects that call getVirtPort() to not cache the
virtual port
since if the CPU changes out from under them it will be worse than useless.
Perhaps a null
function like delVirtPort() is still useful in that case.
diff --git a/src/arch/alpha/utility.cc b/src/arch/alpha/utility.cc
--- a/src/arch/alpha/utility.cc
+++ b/src/arch/alpha/utility.cc
@@ -49,7 +49,7 @@ uint64_t getArgument(ThreadContext *tc,
return tc-readIntReg(ArgumentReg[number]);
} else {
Addr sp = tc-readIntReg(StackPointerReg);
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
uint64_t arg = vp-readuint64_t(sp +
(number-NumArgumentRegs) * sizeof(uint64_t));
tc-delVirtPort(vp);
diff --git a/src/arch/mips/utility.cc b/src/arch/mips/utility.cc
--- a/src/arch/mips/utility.cc
+++ b/src/arch/mips/utility.cc
@@ -59,7 +59,7 @@ getArgument(ThreadContext *tc, int numbe
return tc-readIntReg(ArgumentReg[number]);
} else {
Addr sp = tc-readIntReg(StackPointerReg);
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
uint64_t arg = vp-readuint64_t(sp +
(number-NumArgumentRegs) * sizeof(uint64_t));
tc-delVirtPort(vp);
diff --git a/src/arch/sparc/utility.cc b/src/arch/sparc/utility.cc
--- a/src/arch/sparc/utility.cc
+++ b/src/arch/sparc/utility.cc
@@ -50,7 +50,7 @@ uint64_t getArgument(ThreadContext *tc,
return tc-readIntReg(ArgumentReg[number]);
} else {
Addr sp = tc-readIntReg(StackPointerReg);
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
uint64_t arg = vp-readuint64_t(sp + 92 +
(number-NumArgumentRegs) * sizeof(uint64_t));
tc-delVirtPort(vp);
diff --git a/src/mem/vport.cc b/src/mem/vport.cc
--- a/src/mem/vport.cc
+++ b/src/mem/vport.cc
@@ -75,7 +75,7 @@ CopyOut(ThreadContext *tc, void *dest, A
CopyOut(ThreadContext *tc, void *dest, Addr src, size_t cplen)
{
uint8_t *dst = (uint8_t *)dest;
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
vp-readBlob(src, dst, cplen);
@@ -87,7 +87,7 @@ CopyIn(ThreadContext *tc, Addr dest, voi
CopyIn(ThreadContext *tc, Addr dest, void *source, size_t cplen)
{
uint8_t *src = (uint8_t *)source;
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
vp-writeBlob(dest, src, cplen);
@@ -99,7 +99,7 @@ CopyStringOut(ThreadContext *tc, char *d
{
int len = 0;
char *start = dst;
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
do {
vp-readBlob(vaddr++, (uint8_t*)dst++, 1);
@@ -112,7 +112,7 @@ void
void
CopyStringIn(ThreadContext *tc, char *src, Addr vaddr)
{
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
for (ChunkGenerator gen(vaddr, strlen(src), TheISA::PageBytes);
!gen.done();
gen.next())
{
diff --git a/src/sim/vptr.hh b/src/sim/vptr.hh
--- a/src/sim/vptr.hh
+++ b/src/sim/vptr.hh
@@ -71,7 +71,7 @@ class VPtr
if (!ptr)
return;
-VirtualPort *port = tc-getVirtPort(tc);
+VirtualPort *port = tc-getVirtPort();
port-readBlob(ptr, buffer, sizeof(T));
tc-delVirtPort(port);
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] After a checkpoint (and thus a stats reset), the not_idle_fraction/notIdleFraction statistic is really wrong
there is a status() accessor method, but nothing uses. It seems
unnecessary to to have a method to read the a variable that only the
object that contains that variable uses.
Ali
On Jun 29, 2008, at 7:45 PM, Ali Saidi wrote:
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1214782927 14400
# Node ID ada5724fbc53640aa6b85ba82e5a43d2e7a67092
# Parent d9de38fba64c204f5eb5ea87adb9b9c0c9e9c1c6
After a checkpoint (and thus a stats reset), the not_idle_fraction/
notIdleFraction statistic is really wrong.
The notIdleFraction statistic isn't updated when the statistics
reset, probably because the cpu Status information
was pulled into the atomic and timing cpus. This changeset pulls
Status back into the BaseSimpleCPU object. Anyone
care to comment on the odd naming of the Status instance? It
shouldn't just be status because that is confusing
with Port::Status, but _status seems a bit strage too.
diff --git a/src/cpu/simple/atomic.cc b/src/cpu/simple/atomic.cc
--- a/src/cpu/simple/atomic.cc
+++ b/src/cpu/simple/atomic.cc
@@ -176,8 +176,6 @@ AtomicSimpleCPU::serialize(ostream os)
{
SimObject::State so_state = SimObject::getState();
SERIALIZE_ENUM(so_state);
-Status _status = status();
-SERIALIZE_ENUM(_status);
BaseSimpleCPU::serialize(os);
nameOut(os, csprintf(%s.tickEvent, name()));
tickEvent.serialize(os);
@@ -188,7 +186,6 @@ AtomicSimpleCPU::unserialize(Checkpoint
{
SimObject::State so_state;
UNSERIALIZE_ENUM(so_state);
-UNSERIALIZE_ENUM(_status);
BaseSimpleCPU::unserialize(cp, section);
tickEvent.unserialize(cp, csprintf(%s.tickEvent, section));
}
@@ -213,7 +210,7 @@ void
void
AtomicSimpleCPU::switchOut()
{
-assert(status() == Running || status() == Idle);
+assert(_status == Running || _status == Idle);
_status = SwitchedOut;
tickEvent.squash();
diff --git a/src/cpu/simple/atomic.hh b/src/cpu/simple/atomic.hh
--- a/src/cpu/simple/atomic.hh
+++ b/src/cpu/simple/atomic.hh
@@ -47,19 +47,6 @@ class AtomicSimpleCPU : public BaseSimpl
virtual ~AtomicSimpleCPU();
virtual void init();
-
- public:
-//
-enum Status {
-Running,
-Idle,
-SwitchedOut
-};
-
- protected:
-Status _status;
-
-Status status() const { return _status; }
private:
diff --git a/src/cpu/simple/base.cc b/src/cpu/simple/base.cc
--- a/src/cpu/simple/base.cc
+++ b/src/cpu/simple/base.cc
@@ -174,12 +174,13 @@ BaseSimpleCPU::resetStats()
BaseSimpleCPU::resetStats()
{
//startNumInst = numInst;
-// notIdleFraction = (_status != Idle);
+ notIdleFraction = (_status != Idle);
}
void
BaseSimpleCPU::serialize(ostream os)
{
+SERIALIZE_ENUM(_status);
BaseCPU::serialize(os);
//SERIALIZE_SCALAR(inst);
nameOut(os, csprintf(%s.xc.0, name()));
@@ -189,6 +190,7 @@ void
void
BaseSimpleCPU::unserialize(Checkpoint *cp, const string section)
{
+UNSERIALIZE_ENUM(_status);
BaseCPU::unserialize(cp, section);
//UNSERIALIZE_SCALAR(inst);
thread-unserialize(cp, csprintf(%s.xc.0, section));
diff --git a/src/cpu/simple/base.hh b/src/cpu/simple/base.hh
--- a/src/cpu/simple/base.hh
+++ b/src/cpu/simple/base.hh
@@ -128,6 +128,20 @@ class BaseSimpleCPU : public BaseCPU
ThreadContext *tc;
protected:
int cpuId;
+
+enum Status {
+Idle,
+Running,
+IcacheRetry,
+IcacheWaitResponse,
+IcacheWaitSwitch,
+DcacheRetry,
+DcacheWaitResponse,
+DcacheWaitSwitch,
+SwitchedOut
+};
+
+Status _status;
public:
diff --git a/src/cpu/simple/timing.cc b/src/cpu/simple/timing.cc
--- a/src/cpu/simple/timing.cc
+++ b/src/cpu/simple/timing.cc
@@ -145,7 +145,7 @@ TimingSimpleCPU::drain(Event *drain_even
{
// TimingSimpleCPU is ready to drain if it's not waiting for
// an access to complete.
-if (status() == Idle || status() == Running || status() ==
SwitchedOut) {
+if (_status == Idle || _status == Running || _status ==
SwitchedOut) {
changeState(SimObject::Drained);
return 0;
} else {
@@ -179,7 +179,7 @@ void
void
TimingSimpleCPU::switchOut()
{
-assert(status() == Running || status() == Idle);
+assert(_status == Running || _status == Idle);
_status = SwitchedOut;
numCycles += tickToCycles(curTick - previousTick);
diff --git a/src/cpu/simple/timing.hh b/src/cpu/simple/timing.hh
--- a/src/cpu/simple/timing.hh
+++ b/src/cpu/simple/timing.hh
@@ -46,24 +46,6 @@ class TimingSimpleCPU : public BaseSimpl
virtual void init();
public:
-//
-enum Status {
-Idle,
-Running,
-IcacheRetry,
-IcacheWaitResponse,
-IcacheWaitSwitch,
-DcacheRetry,
-DcacheWaitResponse,
-DcacheWaitSwitch,
-SwitchedOut
-};
-
- protected:
-Status _status
Re: [m5-dev] [PATCH 2 of 2] Change everything to use the cached virtPort rather than created their own each time
On Jun 29, 2008, at 10:53 PM, Ali Saidi wrote: On Jun 29, 2008, at 8:28 PM, Steve Reinhardt wrote: On Sun, Jun 29, 2008 at 4:49 PM, Ali Saidi [EMAIL PROTECTED] wrote: one question is how to enforce encourage objects that call getVirtPort() to not cache the virtual port since if the CPU changes out from under them it will be worse than useless. Perhaps a null function like delVirtPort() is still useful in that case. I think code not working is a pretty good encouragement mechanism :-). If there are specific things like switchovers that you're concerned about, I'd rather see the effort go into adding (some? more?) switchover cases to the regressions than in devising (or even maintaining) purely psychological techniques like the one you mention. Yes we have no regression tests at the moment. Just how do things break if the CPU switches out anyway? The old CPU is still talking to the same memory system as the new one, right? Yes, but there could not be a cache in the way with that wasn't there before. If it had dirty data then you could copy the wrong value in. On the other hand, if during the switchover the new CPU starts connecting to the same ports that the old one did, won't my once and future patch mean that the old CPU's port gets dicsonnected and hooked up to a defaultPort, which will give you a somewhat relevant error message if you try to reuse a bogus port? Yea, I think so. On second thought it won't. We don't disconnect those ports when a cpu switch happens. Anyone who cached the port would have an invalid copy, but it would still be useable stale data and all. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Parallel M5
On Jun 30, 2008, at 5:15 PM, Steve Reinhardt wrote: On Mon, Jun 30, 2008 at 9:11 AM, Ali Saidi [EMAIL PROTECTED] wrote: The FastAlloc pools and StaticInst cache should clearly be duplicated. Why would you want to duplicate the StaticInst cache? It's a read-mostly structure so you'd only have to lock on a miss/insert, and having a larger shared capacity for a given memory footprint seems like a win to me. Right now we use an stl::map for the cache, so we could try reader/ writer locks, but we couldn't just lock to insert since the insert may cause the read to go off in the weeds unless we make some assumptions about the stl code that I don't think we can make. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] m5: 5 new changesets
changeset 6899b894166f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6899b894166f
summary: After a checkpoint (and thus a stats reset), the
not_idle_fraction/notIdleFraction statistic is really wrong.
changeset 89a6483d7047 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=89a6483d7047
summary: Make the cached virtPort have a thread context so it can do everything
that a newly created one can.
changeset 2af99511ded4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2af99511ded4
summary: Change everything to use the cached virtPort rather than created their
own each time.
changeset 8bfc7650c344 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8bfc7650c344
summary: Remove delVirtPort() and make getVirtPort() only return cached version.
changeset 57e76b2fde15 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=57e76b2fde15
summary: Fix cases where RADV interrupt timer is used and make ITR interrupt
moderation not always delay if no interrupts have been posted for the ITR value.
diffstat:
25 files changed, 19 insertions(+), 59 deletions(-)
src/arch/alpha/stacktrace.cc |1 -
src/arch/alpha/utility.cc |2 +-
src/arch/mips/stacktrace.cc |1 -
src/arch/mips/utility.cc |2 +-
src/arch/sparc/stacktrace.cc |1 -
src/arch/sparc/utility.cc |2 +-
src/arch/x86/stacktrace.cc|1 -
src/base/remote_gdb.cc|2 +-
src/cpu/checker/thread_context.hh |2 +-
src/cpu/o3/thread_context.hh |2 +-
src/cpu/o3/thread_context_impl.hh |4 +---
src/cpu/ozone/cpu.hh |2 --
src/cpu/ozone/cpu_impl.hh |5 -
src/cpu/simple/atomic.hh |6 --
src/cpu/simple/base.cc|2 +-
src/cpu/simple/base.hh|7 +++
src/cpu/simple/timing.hh |9 -
src/cpu/simple_thread.cc | 10 --
src/cpu/simple_thread.hh |4
src/cpu/thread_context.hh |2 +-
src/cpu/thread_state.cc |2 +-
src/cpu/thread_state.hh |2 +-
src/dev/i8254xGBe.cc |1 -
src/mem/vport.cc |5 +
src/sim/vptr.hh |1 -
diffs (truncated from 814 to 300 lines):
diff -r 0d9fac06c402 -r 57e76b2fde15 src/arch/alpha/linux/system.cc
--- a/src/arch/alpha/linux/system.ccSat Jun 28 13:20:00 2008 -0400
+++ b/src/arch/alpha/linux/system.ccTue Jul 01 10:30:08 2008 -0400
@@ -169,7 +169,6 @@ LinuxAlphaSystem::setDelayLoop(ThreadCon
vp = tc-getVirtPort();
vp-writeHtoG(addr, (uint32_t)((cpuFreq / intrFreq) * 0.9988));
-tc-delVirtPort(vp);
}
}
diff -r 0d9fac06c402 -r 57e76b2fde15 src/arch/alpha/stacktrace.cc
--- a/src/arch/alpha/stacktrace.cc Sat Jun 28 13:20:00 2008 -0400
+++ b/src/arch/alpha/stacktrace.cc Tue Jul 01 10:30:08 2008 -0400
@@ -71,8 +71,6 @@ namespace AlphaISA
if (!tc-getSystemPtr()-kernelSymtab-findAddress(task_struct_comm,
addr))
panic(thread info not compiled into kernel\n);
name_off = vp-readGtoHint32_t(addr);
-
-tc-delVirtPort(vp);
}
Addr
@@ -88,7 +86,6 @@ namespace AlphaISA
vp = tc-getVirtPort();
tsk = vp-readGtoHAddr(base + task_off);
-tc-delVirtPort(vp);
return tsk;
}
@@ -106,7 +103,6 @@ namespace AlphaISA
vp = tc-getVirtPort();
pd = vp-readGtoHuint16_t(task + pid_off);
-tc-delVirtPort(vp);
return pd;
}
diff -r 0d9fac06c402 -r 57e76b2fde15 src/arch/alpha/utility.cc
--- a/src/arch/alpha/utility.cc Sat Jun 28 13:20:00 2008 -0400
+++ b/src/arch/alpha/utility.cc Tue Jul 01 10:30:08 2008 -0400
@@ -49,10 +49,9 @@ uint64_t getArgument(ThreadContext *tc,
return tc-readIntReg(ArgumentReg[number]);
} else {
Addr sp = tc-readIntReg(StackPointerReg);
-VirtualPort *vp = tc-getVirtPort(tc);
+VirtualPort *vp = tc-getVirtPort();
uint64_t arg = vp-readuint64_t(sp +
(number-NumArgumentRegs) * sizeof(uint64_t));
-tc-delVirtPort(vp);
return arg;
}
#else
diff -r 0d9fac06c402 -r 57e76b2fde15 src/arch/mips/linux/system.cc
--- a/src/arch/mips/linux/system.cc Sat Jun 28 13:20:00 2008 -0400
+++ b/src/arch/mips/linux/system.cc Tue Jul 01 10:30:08 2008 -0400
@@ -168,7 +168,6 @@ LinuxMipsSystem::setDelayLoop(ThreadCont
vp = tc-getVirtPort();
vp-writeHtoG(addr, (uint32_t)((cpuFreq / intrFreq) * 0.9988));
-tc-delVirtPort(vp);
}
}
diff -r 0d9fac06c402 -r 57e76b2fde15 src/arch/mips/stacktrace.cc
--- a/src/arch/mips/stacktrace.cc Sat Jun 28 13:20:00 2008 -0400
+++ b/src/arch/mips/stacktrace.cc Tue Jul 01 10:30:08 2008 -0400
@@ -70,8 +70,6 @@ ProcessInfo::ProcessInfo(ThreadContext *
// if (!tc-getSystemPtr()-kernelSymtab-findAddress(task_struct_comm,
addr))
//
Re: [m5-dev] Regression
Ummm... why are their output file differences? All the regressions have been passing just fine. Ali On Jul 21, 2008, at 8:12 PM, nathan binkert wrote: I'm running a full regression on zizzer right now and I'm going to commit all of the changes since there are a bunch of output file differences right now. Any problems with that? Nate ___ 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] submit patches: Mesh2D, directory coherence, and multithreading
Hi Jiayuan, I've just briefly started looking at your patches. All of them compile with the exception of SimpleMultiThreads.patch. When I attempt to compile it I get the following errors: In file included from build/ALPHA_FS/cpu/simple/atomic.hh:35, from build/ALPHA_FS/cpu/simple/atomic.cc:37: build/ALPHA_FS/cpu/simple/base.hh: In member function ‘void BaseSimpleCPU::ev5_trap(Fault)’: build/ALPHA_FS/cpu/simple/base.hh:450: error: ‘tc’ was not declared in this scope cc1plus: warnings being treated as errors build/ALPHA_FS/sim/host.hh: At global scope: build/ALPHA_FS/sim/host.hh:61: warning: ‘MaxTick’ defined but not used build/ALPHA_FS/arch/alpha/isa_traits.hh:164: warning: ‘AlphaISA::SyscallPseudoReturnReg’ defined but not used distcc[24660] ERROR: compile build/ALPHA_FS/cpu/simple/atomic.cc on @zizzer.pool/12 failed scons: *** [build/ALPHA_FS/cpu/simple/atomic.o] Error 1 In file included from build/ALPHA_FS/cpu/simple/timing.hh:35, from build/ALPHA_FS/cpu/simple/timing.cc:37: build/ALPHA_FS/cpu/simple/base.hh: In member function ‘void BaseSimpleCPU::ev5_trap(Fault)’: build/ALPHA_FS/cpu/simple/base.hh:450: error: ‘tc’ was not declared in this scope cc1plus: warnings being treated as errors build/ALPHA_FS/sim/host.hh: At global scope: build/ALPHA_FS/sim/host.hh:61: warning: ‘MaxTick’ defined but not used build/ALPHA_FS/arch/alpha/isa_traits.hh:164: warning: ‘AlphaISA::SyscallPseudoReturnReg’ defined but not used distcc[24671] ERROR: compile build/ALPHA_FS/cpu/simple/timing.cc on @zizzer.pool/12 failed scons: *** [build/ALPHA_FS/cpu/simple/timing.o] Error 1 In file included from build/ALPHA_FS/cpu/simple/base.cc:45: build/ALPHA_FS/cpu/simple/base.hh: In member function ‘void BaseSimpleCPU::ev5_trap(Fault)’: build/ALPHA_FS/cpu/simple/base.hh:450: error: ‘tc’ was not declared in this scope cc1plus: warnings being treated as errors build/ALPHA_FS/cpu/simple/base.cc: In constructor ‘BaseSimpleCPU::BaseSimpleCPU(BaseSimpleCPU::Params*)’: build/ALPHA_FS/cpu/simple/base.cc:91: warning: unused variable ‘next_thread_id’ build/ALPHA_FS/sim/host.hh: At global scope: build/ALPHA_FS/sim/host.hh:61: warning: ‘MaxTick’ defined but not used build/ALPHA_FS/arch/alpha/isa_traits.hh:164: warning: ‘AlphaISA::SyscallPseudoReturnReg’ defined but not used distcc[24680] ERROR: compile build/ALPHA_FS/cpu/simple/base.cc on @zizzer.pool/12 failed scons: *** [build/ALPHA_FS/cpu/simple/base.o] Error 1 Is part of the patch missing? Thanks, Ali On Jul 29, 2008, at 10:29 AM, Jiayuan Meng wrote: Hey Nathan and all, Thanks for the support! Here is a preview version, you can download the patches from: http://www.cs.virginia.edu/~jm6dg/fractal/m5patches.htm I'm open to any comments/suggestions. Let me know if you have any questions. Thanks! Jiayuan - Original Message - From: nathan binkert [EMAIL PROTECTED] To: M5 Developer List m5-dev@m5sim.org Sent: 2008年7月12日 7:50 AM Subject: Re: [m5-dev] submit patches: Mesh2D, directory coherence,and multithreading Wow, that's fantastic. The best thing you can do is get your code working with the new repository using mercurial and mercurial queues. If you do that, then we can work with you to make sure that the code meets all of the requirements (doesn't break things, is reasonably organized, meets the style guidelines, etc.) Did you use a revision control system as you did your work? Thanks, Nate 2008/7/11 jiayuan meng [EMAIL PROTECTED]: Dear all, I appreciate all your support to help me with M5. I really love it. I'm a graduate student working with Prof. Kevin Skadron at University of Virginia. And now, I'd like to submit patches to M5 that enables it to simulate CMP architecture. I have a mesh2D model that works well with an MSI directory coherence protocol. Both the interconnection and directory coherence models are extendable. Another patch is to support multithreading for simple CPUs. The cpu can switch to another HW thread context if it has a data access. However, atomic modes are not well tested. And I haven't considered checkpoints. The mercurial patches are based on changeset 5291:456a50cf2a67, a version after 2.0beta4 but before 2.0beta5. As an external developer, how do you think I should submit the patches? An do you think it would be necessary to update the patches so they are based on a more recent changeset? If so, which changeset? Just hope it might be useful. Thanks! Jiayuan Meng Need to know now? Get instant answers with Windows Live Messenger. IM on your terms. ___ 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] changeset in m5: Return an UnimpFault for an ITB translation of ...
changeset d8ab33f5ff9a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d8ab33f5ff9a
description:
Return an UnimpFault for an ITB translation of an uncachable address.
We don't support fetching from uncached addresses in Alpha and it means that a
speculative fetch can clobber device registers.
diffstat:
0 files changed
diffs (46 lines):
diff -r a5ff5e57fafd -r d8ab33f5ff9a src/arch/alpha/tlb.cc
--- a/src/arch/alpha/tlb.cc Mon Aug 11 14:47:49 2008 -0700
+++ b/src/arch/alpha/tlb.cc Wed Aug 13 16:29:59 2008 -0400
@@ -116,7 +116,7 @@
Fault
-TLB::checkCacheability(RequestPtr req)
+TLB::checkCacheability(RequestPtr req, bool itb)
{
// in Alpha, cacheability is controlled by upper-level bits of the
// physical address
@@ -148,6 +148,12 @@
req-setPaddr(req-getPaddr() PAddrUncachedMask);
#endif
}
+// We shouldn't be able to read from an uncachable address in Alpha as
+// we don't have a ROM and we don't want to try to fetch from a device
+// register as we destroy any data that is clear-on-read.
+if (req-isUncacheable() itb)
+return new UnimpFault(CPU trying to fetch from uncached I/O);
+
}
return NoFault;
}
@@ -390,7 +396,7 @@
if (req-getPaddr() ~PAddrImplMask)
return genMachineCheckFault();
-return checkCacheability(req);
+return checkCacheability(req, true);
}
diff -r a5ff5e57fafd -r d8ab33f5ff9a src/arch/alpha/tlb.hh
--- a/src/arch/alpha/tlb.hh Mon Aug 11 14:47:49 2008 -0700
+++ b/src/arch/alpha/tlb.hh Wed Aug 13 16:29:59 2008 -0400
@@ -92,7 +92,7 @@
return (unimplBits == 0) || (unimplBits == EV5::VAddrUnImplMask);
}
-static Fault checkCacheability(RequestPtr req);
+static Fault checkCacheability(RequestPtr req, bool itb = false);
// Checkpointing
virtual void serialize(std::ostream os);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: More subtle fixes to how interrupts are suppose...
changeset 92b89377be48 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=92b89377be48
description:
More subtle fixes to how interrupts are supposed to work in the device.
Fix postedInterrupts statistics.
diffstat:
0 files changed
diffs (59 lines):
diff -r d8ab33f5ff9a -r 92b89377be48 src/dev/i8254xGBe.cc
--- a/src/dev/i8254xGBe.cc Wed Aug 13 16:29:59 2008 -0400
+++ b/src/dev/i8254xGBe.cc Wed Aug 13 16:30:30 2008 -0400
@@ -588,7 +588,6 @@
if (interEvent.scheduled()) {
interEvent.deschedule();
}
-postedInterrupts++;
cpuPostInt();
} else {
Tick int_time = lastInterrupt + itr_interval;
@@ -611,6 +610,8 @@
void
IGbE::cpuPostInt()
{
+
+postedInterrupts++;
if (!(regs.icr() regs.imr)) {
DPRINTF(Ethernet, Interrupt Masked. Not Posting\n);
diff -r d8ab33f5ff9a -r 92b89377be48 src/dev/i8254xGBe.hh
--- a/src/dev/i8254xGBe.hh Wed Aug 13 16:29:59 2008 -0400
+++ b/src/dev/i8254xGBe.hh Wed Aug 13 16:30:30 2008 -0400
@@ -87,7 +87,7 @@
void rdtrProcess() {
rxDescCache.writeback(0);
DPRINTF(EthernetIntr, Posting RXT interrupt because RDTR timer
expired\n);
-postInterrupt(iGbReg::IT_RXT, true);
+postInterrupt(iGbReg::IT_RXT);
}
//friend class EventWrapperIGbE, IGbE::rdtrProcess;
@@ -97,7 +97,7 @@
void radvProcess() {
rxDescCache.writeback(0);
DPRINTF(EthernetIntr, Posting RXT interrupt because RADV timer
expired\n);
-postInterrupt(iGbReg::IT_RXT, true);
+postInterrupt(iGbReg::IT_RXT);
}
//friend class EventWrapperIGbE, IGbE::radvProcess;
@@ -107,7 +107,7 @@
void tadvProcess() {
txDescCache.writeback(0);
DPRINTF(EthernetIntr, Posting TXDW interrupt because TADV timer
expired\n);
-postInterrupt(iGbReg::IT_TXDW, true);
+postInterrupt(iGbReg::IT_TXDW);
}
//friend class EventWrapperIGbE, IGbE::tadvProcess;
@@ -117,7 +117,7 @@
void tidvProcess() {
txDescCache.writeback(0);
DPRINTF(EthernetIntr, Posting TXDW interrupt because TIDV timer
expired\n);
-postInterrupt(iGbReg::IT_TXDW, true);
+postInterrupt(iGbReg::IT_TXDW);
}
//friend class EventWrapperIGbE, IGbE::tidvProcess;
EventWrapperIGbE, IGbE::tidvProcess tidvEvent;
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Add the ability for a DMA to tack on an extra d...
changeset 9eaf72819836 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9eaf72819836
description:
Add the ability for a DMA to tack on an extra delay after the DMA is
actually finished.
diffstat:
2 files changed, 3 insertions(+), 3 deletions(-)
src/dev/io_device.cc |2 +-
src/dev/io_device.hh |4 ++--
diffs (86 lines):
diff -r 92b89377be48 -r 9eaf72819836 src/dev/io_device.cc
--- a/src/dev/io_device.cc Wed Aug 13 16:30:30 2008 -0400
+++ b/src/dev/io_device.cc Wed Aug 13 17:41:56 2008 -0400
@@ -138,7 +138,10 @@
state-numBytes += pkt-req-getSize();
assert(state-totBytes = state-numBytes);
if (state-totBytes == state-numBytes) {
-state-completionEvent-process();
+if (state-delay)
+state-completionEvent-schedule(state-delay + curTick);
+else
+state-completionEvent-process();
delete state;
}
delete pkt-req;
@@ -216,13 +219,13 @@
void
DmaPort::dmaAction(Packet::Command cmd, Addr addr, int size, Event *event,
- uint8_t *data)
+ uint8_t *data, Tick delay)
{
assert(event);
assert(device-getState() == SimObject::Running);
-DmaReqState *reqState = new DmaReqState(event, this, size);
+DmaReqState *reqState = new DmaReqState(event, this, size, delay);
DPRINTF(DMA, Starting DMA for addr: %#x size: %d sched: %d\n, addr, size,
@@ -314,7 +317,7 @@
if (state-totBytes == state-numBytes) {
assert(!state-completionEvent-scheduled());
-state-completionEvent-schedule(curTick + lat);
+state-completionEvent-schedule(curTick + lat + state-delay);
delete state;
delete pkt-req;
}
diff -r 92b89377be48 -r 9eaf72819836 src/dev/io_device.hh
--- a/src/dev/io_device.hh Wed Aug 13 16:30:30 2008 -0400
+++ b/src/dev/io_device.hh Wed Aug 13 17:41:56 2008 -0400
@@ -89,8 +89,12 @@
/** Number of bytes that have been acked for this transaction. */
Addr numBytes;
-DmaReqState(Event *ce, Port *p, Addr tb)
-: completionEvent(ce), outPort(p), totBytes(tb), numBytes(0)
+/** Amount to delay completion of dma by */
+Tick delay;
+
+DmaReqState(Event *ce, Port *p, Addr tb, Tick _delay)
+: completionEvent(ce), outPort(p), totBytes(tb), numBytes(0),
+ delay(_delay)
{}
};
@@ -144,7 +148,7 @@
DmaPort(DmaDevice *dev, System *s);
void dmaAction(Packet::Command cmd, Addr addr, int size, Event *event,
- uint8_t *data = NULL);
+ uint8_t *data, Tick delay);
bool dmaPending() { return pendingCount 0; }
@@ -265,14 +269,14 @@
return dynamic_castconst Params *(_params);
}
-void dmaWrite(Addr addr, int size, Event *event, uint8_t *data)
+void dmaWrite(Addr addr, int size, Event *event, uint8_t *data, Tick delay
= 0)
{
-dmaPort-dmaAction(MemCmd::WriteReq, addr, size, event, data);
+dmaPort-dmaAction(MemCmd::WriteReq, addr, size, event, data, delay);
}
-void dmaRead(Addr addr, int size, Event *event, uint8_t *data)
+void dmaRead(Addr addr, int size, Event *event, uint8_t *data, Tick delay
= 0)
{
-dmaPort-dmaAction(MemCmd::ReadReq, addr, size, event, data);
+dmaPort-dmaAction(MemCmd::ReadReq, addr, size, event, data, delay);
}
bool dmaPending() { return dmaPort-dmaPending(); }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Add the ability to specify a think time before ...
changeset 24d9f0941095 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=24d9f0941095
description:
Add the ability to specify a think time before descriptor
fetch/writeback starts/ends as well as after read/write dmas
diffstat:
3 files changed, 7 insertions(+), 1 deletion(-)
src/dev/Ethernet.py |3 +++
src/dev/i8254xGBe.cc |3 ++-
src/dev/i8254xGBe.hh |2 ++
diffs (205 lines):
diff -r 9eaf72819836 -r 24d9f0941095 src/dev/Ethernet.py
--- a/src/dev/Ethernet.py Wed Aug 13 17:41:56 2008 -0400
+++ b/src/dev/Ethernet.py Wed Aug 13 17:41:58 2008 -0400
@@ -98,6 +98,13 @@
InterruptLine = 0x1e
InterruptPin = 0x01
BAR0Size = '128kB'
+wb_delay = Param.Latency('10ns', delay before desc writeback occurs)
+fetch_delay = Param.Latency('10ns', delay before desc fetch occurs)
+fetch_comp_delay = Param.Latency('10ns', delay after desc fetch occurs)
+wb_comp_delay = Param.Latency('10ns', delay after desc wb occurs)
+tx_read_delay = Param.Latency('0ns', delay after tx dma read)
+rx_write_delay = Param.Latency('0ns', delay after rx dma read)
+
class EtherDevBase(EtherDevice):
type = 'EtherDevBase'
diff -r 9eaf72819836 -r 24d9f0941095 src/dev/i8254xGBe.cc
--- a/src/dev/i8254xGBe.cc Wed Aug 13 17:41:56 2008 -0400
+++ b/src/dev/i8254xGBe.cc Wed Aug 13 17:41:58 2008 -0400
@@ -57,7 +57,11 @@
IGbE::IGbE(const Params *p)
: EtherDevice(p), etherInt(NULL), drainEvent(NULL),
useFlowControl(p-use_flow_control),
rxFifo(p-rx_fifo_size), txFifo(p-tx_fifo_size), rxTick(false),
- txTick(false), txFifoTick(false), rxDmaPacket(false), rdtrEvent(this),
radvEvent(this),
+ txTick(false), txFifoTick(false), rxDmaPacket(false),
+ fetchDelay(p-fetch_delay), wbDelay(p-wb_delay),
+ fetchCompDelay(p-fetch_comp_delay), wbCompDelay(p-wb_comp_delay),
+ rxWriteDelay(p-rx_write_delay), txReadDelay(p-tx_read_delay),
+ rdtrEvent(this), radvEvent(this),
tadvEvent(this), tidvEvent(this), tickEvent(this), interEvent(this),
rxDescCache(this, name()+.RxDesc, p-rx_desc_cache_size),
txDescCache(this, name()+.TxDesc, p-tx_desc_cache_size),
@@ -714,7 +718,7 @@
pktPtr = packet;
pktDone = false;
igbe-dmaWrite(igbe-platform-pciToDma(unusedCache.front()-buf),
-packet-length, pktEvent, packet-data);
+packet-length, pktEvent, packet-data, igbe-rxWriteDelay);
}
void
@@ -932,7 +936,7 @@
DPRINTF(EthernetDesc, Starting DMA of packet at offset %d\n, p-length);
igbe-dmaRead(igbe-platform-pciToDma(TxdOp::getBuf(desc)),
-TxdOp::getLen(desc), pktEvent, p-data + p-length);
+TxdOp::getLen(desc), pktEvent, p-data + p-length,
igbe-txReadDelay);
}
diff -r 9eaf72819836 -r 24d9f0941095 src/dev/i8254xGBe.hh
--- a/src/dev/i8254xGBe.hh Wed Aug 13 17:41:56 2008 -0400
+++ b/src/dev/i8254xGBe.hh Wed Aug 13 17:41:58 2008 -0400
@@ -82,6 +82,11 @@
bool txFifoTick;
bool rxDmaPacket;
+
+// Delays in managaging descriptors
+Tick fetchDelay, wbDelay;
+Tick fetchCompDelay, wbCompDelay;
+Tick rxWriteDelay, txReadDelay;
// Event and function to deal with RDTR timer expiring
void rdtrProcess() {
@@ -217,7 +222,8 @@
public:
DescCache(IGbE *i, const std::string n, int s)
: igbe(i), _name(n), cachePnt(0), size(s), curFetching(0),
wbOut(0),
- pktPtr(NULL), fetchEvent(this), wbEvent(this)
+ pktPtr(NULL), wbDelayEvent(this), fetchDelayEvent(this),
+ fetchEvent(this), wbEvent(this)
{
fetchBuf = new T[size];
wbBuf = new T[size];
@@ -244,6 +250,21 @@
void writeback(Addr aMask)
{
+if (wbOut) {
+if (aMask wbAlignment) {
+moreToWb = true;
+wbAlignment = aMask;
+}
+return;
+}
+
+wbAlignment = aMask;
+if (!wbDelayEvent.scheduled())
+wbDelayEvent.schedule(igbe-wbDelay + curTick);
+}
+
+void writeback1()
+{
int curHead = descHead();
int max_to_wb = usedCache.size();
@@ -252,26 +273,13 @@
curHead, descTail(), descLen(), cachePnt, max_to_wb,
descLeft());
-// Check if this writeback is less restrictive that the previous
-// and if so setup another one immediately following it
-if (wbOut (aMask wbAlignment)) {
-moreToWb = true;
-wbAlignment = aMask;
-DPRINTF(EthernetDesc, Writing back already in process,
returning\n);
-return;
-}
-
-
-moreToWb = false;
-wbAlignment = aMask;
-
if (max_to_wb + curHead = descLen()) {
max_to_wb = descLen() - curHead;
moreToWb
[m5-dev] params building
Some recent change causes the params_wrap.cc file to be constantly rebuilt. Every time I build M5 (even if there have been no changes) I see the following swig line: swig -c++ -python -modern -templatereduce -Iext/dnet -I/usr/include/ python2.5 -Ibuild/libelf -Ibuild/ALPHA_FS -outdir build/ALPHA_FS/ params -o build/ALPHA_FS/params/params_wrap.cc build/ALPHA_FS/params/ params.i Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] python only simulation object
You can do a trick like we do for adding the caches to the CPU. Add all of the objects to a member that begins with an underscore and then have a connectAllSouthBridge() function that makes all the connections. Ali On Aug 20, 2008, at 10:20 PM, Gabe Black wrote: I'm working on breaking up the big SouthBridge meta SimObject I have into its components. It would still be handy, however, to have a convenience object in python that would set up all these objects at the right addresses and connect them to each other and a bus appropriately all in one neat package. I tried instantiating such an object as a member of the PC platform to be managed alongside it's other components, but it didn't work because the platform object apparently expects all it's members to be parameters. Is there a better way to approach this, or is this something that should be possible but isn't for some reason? 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
Re: [m5-dev] Configuring the 8254 timer from the platform
Why not have an keep the SouthBridge in the hierarchy to manage the pieces while having them all directly connect to the bus. This seems like a lot of work to get rid of a SimObject in C++ that won't be doing much. Ali On Aug 21, 2008, at 4:46 PM, [EMAIL PROTECTED] wrote: I don't think there's anything wrong with the southbridge as a conceptual object, but I thought having it in the SimObject hierarchy was a bad idea since, for instance in ancient PCs, all the little bits and pieces we're dealing with were their own entities. It's conceivable that in the future these things will even be on die. What I thought would be best was to make all these components first class objects that are directly attached to the bus, etc, but provide a SouthBridge python class that didn't exist beyond the configuration phase and provided a handy conceptual handle on all the bits and pieces and helped set them up properly. Since I don't want the SouthBridge to be between the legacy components and what refers to them (so that that sort of relationship isn't mandantory), I need to find a way to get from the PC object to the timer directly without the timer having to cooperate. What would be best, I think, is if there was some way for a pointer to the timer to persist into C++ without it having to be a Param people could muck with, but I don't think that's currently possible. Gabe Quoting nathan binkert [EMAIL PROTECTED]: What was wrong with the southbridge object? Was it because of the subdevice thing? I don't think you need to necessarily get rid of the southbridge, you can still have it to do the initialization that you want, I just think you want to make all of the things that were subdevices proper SimObjects. Nate On Thu, Aug 21, 2008 at 9:58 AM, [EMAIL PROTECTED] wrote: The problem here isn't the memory locations things are attached at, it's doing some initial configuration on the 8254 which I believe the BIOS would normally do. If you look in the PC init function you can see where this is happening currently. The southBridge pointer (I think) is near the top and it's used to set the value for the timer pointer to point at the 8254. Since the southbridge object no longer exists, that code won't work as is. In order to avoid a loop in SimObject references, I had the SouthBridge set a pointer back to itself in the platform object. I don't want to push that down into the 8254 model because I want to keep that a relatively generic device you could stick anywhere, if you so desired, that doesn't know it's part of the PC platform. Gabe Quoting nathan binkert [EMAIL PROTECTED]: I'm not exactly clear what you're saying here. You had a SouthBridge object, and in south_bridge.cc, it looks like you manually set the memory locations of the various objects in the south bridge. Now, you want to make the individual objects normal SimObjects, but you're having trouble figuring out how to stick them at the right memory locations? What about a simple attachSouthBridge() function in python that take a platform object as a parameter and attaches the various objects at the right memory locations. Alternatively, you could just derive from the PC platform object and stick the south bridge stuff at the right memory locations in there as defaults. Do I understand the problem correctly? Nate On Wed, Aug 20, 2008 at 11:58 PM, Gabe Black [EMAIL PROTECTED] wrote: Now that I'm flattening out the SouthBridge object, I'm ending up breaking the solution I had before to allow the PC platform to program the initial state of the 8254 PIT. What would happen before was that the SouthBridge would tell the PC platform about itself, and then later the platform would get at the timer through the SouthBridge and configure it properly. Now there's no SouthBridge, and I don't want to push the artificial initial configuration code down into the device itself. One possible solution I was thinking of would be to actually just do functional accesses to the right locations to program the PIT like software would. I'm not sure that would work, though, since I don't know if all the devices have been constructed or hooked up to the memory system yet. Another option would be to record in the PC simobject where the timer is since the timer is created and hooked up by the python version. I don't necessarily want to make it a Param though, because I don't want anyone to be able to modify what it's pointing at. All the other connections, to the 8259 PIC, the speaker, etc, will all be to the original object, so it won't do any good for the C++ PC object to initialize something else. Any ideas? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Stable Release
Everyone should hold off pushing patches to the dev tree for the next two weeks so we can create a new stable release. Please only push fixes to known problems and test the repository in the next two weeks. Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Stable Release
From the release notes the following are still outstanding for a 2.0 release. I don't really care about the Cygwin problems and I'm not sure that anyone else does, so I move to strike those. Additionally, we made the repository public so that one is gone. I think the three things that need to be fixed are: O3 CPU -- SMT SE regression hits an assert; bug causing perlbmk to fail (Gabe reported this in April 2007 and I don't know if it's still a problem http://www.m5sim.org/flyspray/task/221); NACKs/coherence messages Statistics -- The CPU statistics are confusing. I think the idle time in the simple CPU can still be wrong after a CPU switch and it's at least not clear to me which idles mean quiesced time or idle because of other things (blocked in the O3 case, not switched out in the simple case); The bus needs statistics; I don't know if the cache statistics are reasonable. Testing -- I've at least done a fair amount of testing over the last month or two, so I'm pretty happy with that. I think some validation needs to be done on an statistics changes though. Ali 1. Fix O3 CPU bug in SE 40.perlbmk fails 2. Fix O3 processing nacks/coherence messages 3. Better statistics for the caches. 4. FS mode doesn't work under Cygwin 5. memtest regression crashes under Cygwin 6. Make repository public 7. Testing 8. Validation On Aug 24, 2008, at 9:55 AM, Ali Saidi wrote: Everyone should hold off pushing patches to the dev tree for the next two weeks so we can create a new stable release. Please only push fixes to known problems and test the repository in the next two weeks. Thanks, Ali ___ 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] changeset in m5: IGbE: Patches I neglected to apply before pushi...
changeset 3bd1fa125989 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3bd1fa125989
description:
IGbE: Patches I neglected to apply before pushing the previous igbe
changeset
diffstat:
2 files changed, 2 insertions(+)
src/dev/i8254xGBe.cc |1 +
src/dev/i8254xGBe.hh |1 +
diffs (186 lines):
diff -r eaeed2bdf50d -r 3bd1fa125989 src/dev/i8254xGBe.cc
--- a/src/dev/i8254xGBe.cc Tue Aug 19 21:59:09 2008 -0700
+++ b/src/dev/i8254xGBe.cc Sun Aug 24 15:27:49 2008 -0400
@@ -587,6 +587,8 @@
regs.icr = regs.icr() | t;
Tick itr_interval = Clock::Int::ns * 256 * regs.itr.interval();
+DPRINTF(EthernetIntr, EINT: postInterrupt() curTick: %d itr: %d interval:
%d\n,
+curTick, regs.itr.interval(), itr_interval);
if (regs.itr.interval() == 0 || now || lastInterrupt + itr_interval =
curTick) {
if (interEvent.scheduled()) {
@@ -652,6 +654,7 @@
intrPost();
+lastInterrupt = curTick;
}
void
@@ -1404,6 +1407,7 @@
txBytes += txFifo.front()-length;
txPackets++;
+txFifoTick = false;
txFifo.pop();
} else {
diff -r eaeed2bdf50d -r 3bd1fa125989 src/dev/i8254xGBe.hh
--- a/src/dev/i8254xGBe.hh Tue Aug 19 21:59:09 2008 -0700
+++ b/src/dev/i8254xGBe.hh Sun Aug 24 15:27:49 2008 -0400
@@ -133,6 +133,8 @@
EventWrapperIGbE, IGbE::tick tickEvent;
+uint64_t macAddr;
+
void rxStateMachine();
void txStateMachine();
void txWire();
@@ -250,23 +252,23 @@
void writeback(Addr aMask)
{
+int curHead = descHead();
+int max_to_wb = usedCache.size();
+
+// Check if this writeback is less restrictive that the previous
+// and if so setup another one immediately following it
if (wbOut) {
if (aMask wbAlignment) {
moreToWb = true;
wbAlignment = aMask;
}
+DPRINTF(EthernetDesc, Writing back already in process,
returning\n);
return;
}
+moreToWb = false;
wbAlignment = aMask;
-if (!wbDelayEvent.scheduled())
-wbDelayEvent.schedule(igbe-wbDelay + curTick);
-}
-
-void writeback1()
-{
-int curHead = descHead();
-int max_to_wb = usedCache.size();
+
DPRINTF(EthernetDesc, Writing back descriptors head: %d tail:
%d len: %d cachePnt: %d max_to_wb: %d descleft: %d\n,
@@ -284,21 +286,35 @@
DPRINTF(EthernetDesc, Writing back %d descriptors\n, max_to_wb);
-if (max_to_wb = 0 || wbOut)
+if (max_to_wb = 0) {
return;
+}
wbOut = max_to_wb;
+assert(!wbDelayEvent.scheduled());
+wbDelayEvent.schedule(igbe-wbDelay + curTick);
+}
+
+void writeback1()
+{
+// If we're draining delay issuing this DMA
+if (igbe-drainEvent) {
+wbDelayEvent.schedule(igbe-wbDelay + curTick);
+return;
+}
+
+DPRINTF(EthernetDesc, Beining DMA of %d descriptors\n, wbOut);
+
for (int x = 0; x wbOut; x++) {
assert(usedCache.size());
-memcpy(wbBuf[x], usedCache[0], sizeof(T));
-delete usedCache[0];
-usedCache.pop_front();
+memcpy(wbBuf[x], usedCache[x], sizeof(T));
+ //delete usedCache[0];
+//usedCache.pop_front();
}
-
assert(wbOut);
-igbe-dmaWrite(igbe-platform-pciToDma(descBase() + curHead *
sizeof(T)),
+igbe-dmaWrite(igbe-platform-pciToDma(descBase() + descHead() *
sizeof(T)),
wbOut * sizeof(T), wbEvent, (uint8_t*)wbBuf,
igbe-wbCompDelay);
}
@@ -310,16 +326,12 @@
void fetchDescriptors()
{
-if (!fetchDelayEvent.scheduled())
-fetchDelayEvent.schedule(igbe-fetchDelay + curTick);
-}
-
-void fetchDescriptors1()
-{
size_t max_to_fetch;
-if (curFetching)
+if (curFetching) {
+DPRINTF(EthernetDesc, Currently fetching %d descriptors,
returning\n, curFetching);
return;
+}
if (descTail() = cachePnt)
max_to_fetch = descTail() - cachePnt;
@@ -329,6 +341,7 @@
size_t free_cache = size - usedCache.size() - unusedCache.size();
max_to_fetch = std::min(max_to_fetch, free_cache);
+
DPRINTF(EthernetDesc, Fetching descriptors head: %d tail:
%d len: %d cachePnt: %d max_to_fetch: %d descleft: %d\n,
@@ -338,9 +351,21 @@
// Nothing to do
if
Re: [m5-dev] Stable Release
There was a change that Ke Meng sent that fixed some problems with O3 in Alpha deadlocking. That fixed quite possibly fixed this as well. Ali On Aug 24, 2008, at 12:24 PM, Gabe Black wrote: I'm pretty sure that perlbmk bug is still there and we just got rid of the regression. It might have gone away on it's own, but I don't think anyone actively tried to fix it. Gabe Ali Saidi wrote: From the release notes the following are still outstanding for a 2.0 release. I don't really care about the Cygwin problems and I'm not sure that anyone else does, so I move to strike those. Additionally, we made the repository public so that one is gone. I think the three things that need to be fixed are: O3 CPU -- SMT SE regression hits an assert; bug causing perlbmk to fail (Gabe reported this in April 2007 and I don't know if it's still a problem http://www.m5sim.org/flyspray/task/221); NACKs/coherence messages Statistics -- The CPU statistics are confusing. I think the idle time in the simple CPU can still be wrong after a CPU switch and it's at least not clear to me which idles mean quiesced time or idle because of other things (blocked in the O3 case, not switched out in the simple case); The bus needs statistics; I don't know if the cache statistics are reasonable. Testing -- I've at least done a fair amount of testing over the last month or two, so I'm pretty happy with that. I think some validation needs to be done on an statistics changes though. Ali 1. Fix O3 CPU bug in SE 40.perlbmk fails 2. Fix O3 processing nacks/coherence messages 3. Better statistics for the caches. 4. FS mode doesn't work under Cygwin 5. memtest regression crashes under Cygwin 6. Make repository public 7. Testing 8. Validation On Aug 24, 2008, at 9:55 AM, Ali Saidi wrote: Everyone should hold off pushing patches to the dev tree for the next two weeks so we can create a new stable release. Please only push fixes to known problems and test the repository in the next two weeks. Thanks, Ali ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] regression on debug/opt
The changeset that caused this was: changeset: 5520:cf280b3621cf user:Steve Reinhardt [EMAIL PROTECTED] date:Sun Aug 03 18:13:29 2008 -0400 summary: Make default PhysicalMemory latency slightly more realistic. It must be a latent bug that was exposed when Steve changed the default the default memory latency to 30ns. Ali On Aug 11, 2008, at 3:43 PM, nathan binkert wrote: I just noticed that the smt regression fails an assertion now, but this was never noticed because we only run m5.fast for the regressions now. Anyone have time to bisect it? More details. Gmail has been bizarre today. We're failing an assertion in: ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing I noticed it because I ran a regression with m5.opt, but we normally only run m5.fast for the nightly regressions. FullO3CPUImpl::removeThread(unsigned int) [with Impl = AlphaSimpleImpl]: Assertion `iew.ldstQueue.getCount(tid) == 0' failed. Program aborted at cycle 13914000 ___ 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] Stable Release
Because the machines were busy, which meant that the jobs timed out. Ali On Aug 24, 2008, at 12:45 PM, Gabe Black wrote: We should also figure out why the all regressions failed completely last night. Gabe Black wrote: I'm pretty sure that perlbmk bug is still there and we just got rid of the regression. It might have gone away on it's own, but I don't think anyone actively tried to fix it. Gabe Ali Saidi wrote: From the release notes the following are still outstanding for a 2.0 release. I don't really care about the Cygwin problems and I'm not sure that anyone else does, so I move to strike those. Additionally, we made the repository public so that one is gone. I think the three things that need to be fixed are: O3 CPU -- SMT SE regression hits an assert; bug causing perlbmk to fail (Gabe reported this in April 2007 and I don't know if it's still a problem http://www.m5sim.org/flyspray/task/221); NACKs/coherence messages Statistics -- The CPU statistics are confusing. I think the idle time in the simple CPU can still be wrong after a CPU switch and it's at least not clear to me which idles mean quiesced time or idle because of other things (blocked in the O3 case, not switched out in the simple case); The bus needs statistics; I don't know if the cache statistics are reasonable. Testing -- I've at least done a fair amount of testing over the last month or two, so I'm pretty happy with that. I think some validation needs to be done on an statistics changes though. Ali 1. Fix O3 CPU bug in SE 40.perlbmk fails 2. Fix O3 processing nacks/coherence messages 3. Better statistics for the caches. 4. FS mode doesn't work under Cygwin 5. memtest regression crashes under Cygwin 6. Make repository public 7. Testing 8. Validation On Aug 24, 2008, at 9:55 AM, Ali Saidi wrote: Everyone should hold off pushing patches to the dev tree for the next two weeks so we can create a new stable release. Please only push fixes to known problems and test the repository in the next two weeks. Thanks, Ali ___ 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 ___ 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] forward declaration typedef
Is there a way to forward declare a typedef? We used PacketPtr and RequestPtr all over the place in header files which requires including packet.hh and request.hh. However, in many cases the only reason we need to include the header files is because of the typedef. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] forward declaration typedef
PacketPtr and PacketReq aren't reference counting. We just starting using them incase we wanted reference counting pointers. Looking at the code we do a reasonably job of using PacketPtr everywhere, but RequestPtr is used maybe 40% of the time. Ali On Aug 24, 2008, at 3:20 PM, Gabe Black wrote: nathan binkert wrote: Is there a way to forward declare a typedef? We used PacketPtr and RequestPtr all over the place in header files which requires including packet.hh and request.hh. However, in many cases the only reason we need to include the header files is because of the typedef. There is no way to forward declare a typedef, though you can just define the typedef twice. We could create a file like src/mem/forward.hh and stick the few typedefs that we need in it. iosfwd from the standard library is an example of this sort of file. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I may be mangling this a little since I haven't looked at it in a while, but I think there's a basically unbreakable string of dependencies between, for instance, PacketPtr and the Packet class, namely PacketPtr typedef = PacketPtr reference counting pointer = Packet class. I think it's pretty much reduced to just those elements as is, so all you'd be doing is moving it around. Can you forward declare the reference counting pointer class and then use it in a typedef? I was under the impression you couldn't. 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] Fwd: RFC: stacks - patch management extension inspired by bzr-loom
This sounds interesting. Ali Begin forwarded message: From: Peter Arrenbrecht [EMAIL PROTECTED] Date: August 26, 2008 11:26:31 AM GMT-04:00 To: mercurial [EMAIL PROTECTED] Subject: RFC: stacks - patch management extension inspired by bzr-loom Reply-To: [EMAIL PROTECTED] Hi all I've started work on what I call stacks: http://arrenbrecht.ch/mercurial/stacks.htm It's about using hierarchical branching to develop a patch series collaboratively (as opposed to exchanging versioned mq repos). It is still quite rudimentary and experimental, but if anyone wants to give early feedback, I'd welcome it (release early, release often - so there). It's also my first attempt at literate testing in the context of Mercurial (like I believe the hgbook examples work). Currently it relies on Rextile[1] markup, but if this style of testing is going to be deemed valuable, I can later switch to whatever markup we shall agree on. From the introduction: Stacked patch branches (stacks) is a way to develop a stack of patches for submission into a main repo. This is for when the main repo does not want to track the detailed evolution of the patches, so you cannot use plain branching and merging. But during the patches' development, you do want to track the detailed evolution and want to collaborate with team members as naturally as on a normal branch, including exchange and reviewing of changesets. So stacks allow to develop patches as basically normal Mercurial branches, which later get thrown away (or archived) when the patches have been accepted. Stacks is thus an alternative for mq. While mq is very useful for fairly short-lived, single-person patches, I find it lacking for long-term and/or team efforts. Versioned mq patch queues are hard to review (diffs of diffs) and merge, and we lack the usual merging niceness in Mercurial when updating later patches to changes in earlier ones. -parren [1]http://arrenbrecht.ch/rextile/ ___ Mercurial mailing list [EMAIL PROTECTED] http://selenic.com/mailman/listinfo/mercurial ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] [PATCH] Make m5term use select() so OS X is happy
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1220389563 14400
# Node ID 5de467c4d71880ff9767158561e8490c4afaeaf0
# Parent 6a27bc3fc267be638942ba02ac058812aaed86da
Make m5term use select() so OS X is happy.
diff --git a/util/term/term.c b/util/term/term.c
--- a/util/term/term.c
+++ b/util/term/term.c
@@ -144,49 +144,51 @@
void
readwrite(int nfd)
{
-struct pollfd pfd[2];
+fd_set read_fds, write_fds;
char buf[BUFSIZ];
-int wfd = fileno(stdin), n, ret;
+int wfd = fileno(stdin), n, ret, max_fd;
int lfd = fileno(stdout);
int escape = 0;
-/* Setup Network FD */
-pfd[0].fd = nfd;
-pfd[0].events = POLLIN;
-/* Setup STDIN FD */
-pfd[1].fd = wfd;
-pfd[1].events = POLLIN;
+if (nfd == -1)
+return;
-while (pfd[0].fd != -1) {
-if ((n = poll(pfd, 2, -1)) 0) {
+FD_ZERO(read_fds);
+FD_ZERO(write_fds);
+
+FD_SET(wfd, read_fds);
+FD_SET(nfd, read_fds);
+max_fd = nfd + 1;
+printf(wfd: %d nfd: %d\n, wfd, nfd);
+
+while (1) {
+n = select(max_fd, read_fds, write_fds, NULL, NULL);
+if (n 0) {
close(nfd);
-err(1, Polling Error);
+perror(Select Error:);
}
-if (n == 0)
+if (n == 0) {
return;
+}
-if (pfd[0].revents POLLIN) {
+if (FD_ISSET(nfd, read_fds)) {
if ((n = read(nfd, buf, sizeof(buf))) 0)
return;
else if (n == 0) {
shutdown(nfd, SHUT_RD);
-pfd[0].fd = -1;
-pfd[0].events = 0;
} else {
if ((ret = atomicio(write, lfd, buf, n)) != n)
return;
}
}
-if (pfd[1].revents POLLIN) {
+if (FD_ISSET(wfd, read_fds)) {
if ((n = read(wfd, buf, sizeof(buf))) 0)
return;
else if (n == 0) {
shutdown(nfd, SHUT_WR);
-pfd[1].fd = -1;
-pfd[1].events = 0;
} else {
if (escape) {
char buf2[] = ~;
@@ -208,7 +210,10 @@
return;
}
}
-}
+FD_ZERO(read_fds);
+FD_SET(wfd, read_fds);
+FD_SET(nfd, read_fds);
+} // while
}
void
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [PATCH] Make m5term use select() so OS X is happy
I finally sat down and made the m5term work with OS X. I haven't
tested it that much, so please give it a try and let me know if
anything is broken.
Ali
On Sep 2, 2008, at 5:07 PM, Ali Saidi wrote:
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1220389563 14400
# Node ID 5de467c4d71880ff9767158561e8490c4afaeaf0
# Parent 6a27bc3fc267be638942ba02ac058812aaed86da
Make m5term use select() so OS X is happy.
diff --git a/util/term/term.c b/util/term/term.c
--- a/util/term/term.c
+++ b/util/term/term.c
@@ -144,49 +144,51 @@
void
readwrite(int nfd)
{
-struct pollfd pfd[2];
+fd_set read_fds, write_fds;
char buf[BUFSIZ];
-int wfd = fileno(stdin), n, ret;
+int wfd = fileno(stdin), n, ret, max_fd;
int lfd = fileno(stdout);
int escape = 0;
-/* Setup Network FD */
-pfd[0].fd = nfd;
-pfd[0].events = POLLIN;
-/* Setup STDIN FD */
-pfd[1].fd = wfd;
-pfd[1].events = POLLIN;
+if (nfd == -1)
+return;
-while (pfd[0].fd != -1) {
-if ((n = poll(pfd, 2, -1)) 0) {
+FD_ZERO(read_fds);
+FD_ZERO(write_fds);
+
+FD_SET(wfd, read_fds);
+FD_SET(nfd, read_fds);
+max_fd = nfd + 1;
+printf(wfd: %d nfd: %d\n, wfd, nfd);
+
+while (1) {
+n = select(max_fd, read_fds, write_fds, NULL, NULL);
+if (n 0) {
close(nfd);
-err(1, Polling Error);
+perror(Select Error:);
}
-if (n == 0)
+if (n == 0) {
return;
+}
-if (pfd[0].revents POLLIN) {
+if (FD_ISSET(nfd, read_fds)) {
if ((n = read(nfd, buf, sizeof(buf))) 0)
return;
else if (n == 0) {
shutdown(nfd, SHUT_RD);
-pfd[0].fd = -1;
-pfd[0].events = 0;
} else {
if ((ret = atomicio(write, lfd, buf, n)) != n)
return;
}
}
-if (pfd[1].revents POLLIN) {
+if (FD_ISSET(wfd, read_fds)) {
if ((n = read(wfd, buf, sizeof(buf))) 0)
return;
else if (n == 0) {
shutdown(nfd, SHUT_WR);
-pfd[1].fd = -1;
-pfd[1].events = 0;
} else {
if (escape) {
char buf2[] = ~;
@@ -208,7 +210,10 @@
return;
}
}
-}
+FD_ZERO(read_fds);
+FD_SET(wfd, read_fds);
+FD_SET(nfd, read_fds);
+} // while
}
void
___
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] bug in x86
I would say that it probably doesn't matter since I doubt anyone is using x86. We're trying to get a new stable release ready anyway, so we should probably just wait for that. Ali On Sep 2, 2008, at 5:23 PM, Steve Reinhardt wrote: It's fine with me, since it probably doesn't touch anything that's widely used... if no one else objects, I'd say go for it. Steve On Tue, Sep 2, 2008 at 2:19 PM, [EMAIL PROTECTED] wrote: Quoting Gabe Black [EMAIL PROTECTED]: Specifying the right bus in the MP tables partially fixed the kernel's handling of interrupts, but there was also a semi-corner case bug in how one of the instructions was microcoded which was also partially breaking things. I have a patch and I've verified it fixes the problem, and I'm running the X86_SE regressions on zizzer to see if those changed and to update them if appropriate. My question is, should I push this into the stable repo? I'm thinking yes but I figured I'd check before needlessly causing headaches. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev Somebody? Anybody? ___ 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] interrupt messages
I don't think there should be any problem with these working. Ali On Sep 5, 2008, at 2:48 AM, Gabe Black wrote: More concretely, if you look in appendix F of the third Intel manual, it shows the formats of the messages the APICs would send each other over the special purpose APIC bus. I'm not intending to implement one since they've used the system bus instead for quite a while, but that at least shows the quantity of information going back and forth. There's also an arbitration ID which goes away when you use the system bus, so these messages can probably be simpler than what's in the appendix. I'd guess around 64 to 128 bits per message. Gabe [EMAIL PROTECTED] wrote: The accesses are supposed to be atomic, I'm pretty sure. I think they're basically just special messages passed around on the bus which I'm approximating with reads and writes. I set aside a page for those accesses because it was a convenient size and I already needed a second page for access to the local APICs configuration space, but I don't expect anywhere near that much data to actually go into these messages. It should just be a handful of bytes. What might be best would be to create some new type/command for packets that represent interrupt messages, but I initially shied away from that because it might be hard to implement properly, could make all the devices more complex since they have to handle or at least ignore those messages, and adds clutter and complexity to the way the memory system works. I'm pretty open to suggestions if there's some way to implement things that seems obviously best. Gabe Quoting Steve Reinhardt [EMAIL PROTECTED]: The memory system doesn't do any segmentation. It will choke if you try and do a single access that spans cache blocks in cached memory. For uncached physical accesses, I don't know if there are any hard limits or not, but performance would get unrealistic if you tie up a bus while a full page of data traverses it. There are ports that provide readBlob/writeBlob calls, though they're really only intended for functional accesses (like program loading, syscall emulation, etc.). I don't know enough detail about the APIC accesses to comment on the atomicity issues. I'd expect that it's designed so that you just do atomic accesses. Steve On Thu, Sep 4, 2008 at 9:23 AM, Gabe Black [EMAIL PROTECTED] wrote: I'm close to the point of sending messages between APICs, and I was thinking about the semantics of how I actually want to send the message. I need to know the specifics of a few properties of the memory system in order to be sure it will work. First, if I send a bigger message, is it possible it'll be split up before getting to it's destination? Second, if it is split up, is there any guarantee of ordering? Third, is there any easy socket style mechanism to send a bunch of bytes to one location (a bunch of small, sequential writes seems fairly clunky), or would I want to write into a buffer and then somehow signal it was all in there? I've allocated a page of memory space for each APIC so they have a space to send each other messages. I suppose a fourth concern if the buffer approach is used is that multiple APICs could compete to write into the same portion of the APICs page unless it was further divided into regions for each sender. 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-de ___ 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] Stable
Statistics cleanup? gcc 4.2? Ali On Sep 6, 2008, at 1:25 PM, nathan binkert wrote: What's still left to do for stable? There's the SMT regression failure. Korey or Kevin can you guys look into that so we can get this done? Is there anything else? I have stuff just waiting to get into the tree and I'm holding off for this stable release. Nate ___ 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] intdev
On Sep 6, 2008, at 4:26 PM, Gabe Black wrote: There are two major problems with using the DmaPort. First, I'd want to send the interrupt -now- not when the DMA queuing latency, etc gets used up. Second, DmaPort will fragment a packet which, while maybe necessary in some cases, will break the atomicity requirements for the interrupt messages and might even make the parts of it get there out of order. While it may not -normally- fragment the message, if it does things will be broken. I would rather not use something where such a large portion of its functionality is either not needed or counterproductive. The only time the DMA port will break up the packet is if it's larger than a cache block. I can't imagine an interrupt message being that large. With MSI, interrupts don't magically get propagated. They device still has to arbitrate for the bus. Ali Also, I agree the interrupt stuff should make it into the other ISAs. That's at least part of why I'm trying to build the parts that make sense outside of x86 into a separate object other things can use, and why I'm trying to avoid forcing a particular subclass or flavor of MemObject onto the various PICs. I don't know if the Intel APIC would work even with nice default values because the way it's configured is probably at least enough different from what other ISAs use that it wouldn't work without some sort of adapter layer in place. In that case, the APIC itself might as well be the adapter layer that implements the ISA interface on top of the underlying communication mechanism which is what I'm going for. In any case, I need to get it working for x86 first so I'll worry about putting in the necessary hooks and parameters in later revisions. But like I said, I definitely agree pushing this into other ISAs is important and that will be a consideration for how things go together. Gabe nathan binkert wrote: I have two major comments. First, you can use a DmaPort so you can transmit an receive. Second, whatever ends up happening with interrupts, I'd like us to look fixing up all of the interrupt mechanism for all ISAs while we're at it. It's already pretty disgusting. I'd like to see all ISAs send interrupts over the memory system (we can just use the intel APIC for everything with nice default values). Nate On Fri, Sep 5, 2008 at 11:57 PM, Gabe Black [EMAIL PROTECTED] wrote: I'm working on making the various interrupt controllers talk to each other, and I'm expecting to run into a tricky situation with multiple inheritance. First, my patch queue is on daystrom as x86-patches if you want to look at what I'm talking about directly. There are quite a few patches which do a lot, but you'd mostly be interested in the later ones having apic in their names. Anyway, to make the PICs and APICs and interrupt sources connect to each other nicely, I created a class called IntDev and a class called IntPin. IntDev is intended to be a base for anything that can accept interrupts, and IntPin is a small class exposed through python that refers to an IntDev and has a pin number. The python version of IntDevs have a function called pin(line) which returns an IntPin associated with the device and recording the correct pin. When this gets to the C+ + side of things, a device triggers its interrupt by calling a function on the IntPin which calls a function on the IntDev and passes it the appropriate line. This makes things much cleaner in general, and I'm pretty happy with it. Then I started working on the APICs and getting them to talk to each other, and I realize the PioPort doesn't let you -send- anything, just receive. That's what it's supposed to do, and I don't think it would be appropriate to try to change that, although I considered suggesting that. I thought about it more, and it occurred to me that both APICs have both pio aspects and interrupt message aspects which could be represented separately. The IO APIC needs to be a PioDevice because it does the same index/window trick the CMOS and PCI configuration space use, and the Local APIC can be a BasicPioDevice. On top of that, they can also have a second port which handles all the interrupt messages between them and knows how to send and receive the messages in an appropriate way. That way I don't have to reinvent the PioPort, mess it up trying to make it work with interrupts, or mingle the two systems. The next thing I thought of was that it would be handy to make this part of the IntDev class which all (A)PICs already inherit from and which fits this type of functionality. The PICs don't actually communicate on the system bus, but they can ignore the interrupt port and not attach it to anything and it would work fine. This could also hook into the same mechanism already used to trigger interrupts through the IntDev base class,
Re: [m5-dev] Detecting gcc
Seems reasonable to me. Ali On Sep 8, 2008, at 6:32 PM, nathan binkert wrote: I'm trying to get thing working in gcc 4.3, so I installed a beta of intrepid ibex. The first bug was that the logic for detecting GCC is wrong in some way. How about the attached diff. It seems right for old ubuntu, new ubuntu, fedora, and my mac. Nate cxx.diff___ 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] interrupts interface
I don't think this optimization will work. The reason that the get and update parts were separated was because getInterupt() is supposed to be callable without changing the interrupt/system state. If memory serves the reason for this is because there are cases where you might call get a fault multiple places interrupt + itb fault + something else and the fault priority the ISA specifies is not the order which we would generate things. The two step process allows us to fix that up. Ali On Sep 8, 2008, at 2:01 AM, Gabe Black wrote: Since I've been poking around the Interrupts object, I've noticed we've got a lot of functions on there, and we can probably trim that down a bit. There are functions related to setting and clearing interrupts which go away when those are delivered through the memory system, although that transition will take a while and I'm not planning on it any time soon. Also, there are three functions related to getting an interrupt to process. There's check_interrupts which returns a bool of whether or not there's an interrupt waiting, getInterrupt which actually retrieves the interrupt, and updateIntrInfo which records the fact that the interrupt is about to happen in the ThreadContext. What I think will work and be a bit more streamline is to combine getInterrupt and updateIntrInfo into one function called, for instance, acceptInterrupt. This way you can check whether an interrupt is ready whenever you want without going through the overhead of actually generating it, and when you're ready to actually invoke it, you can do that all in one shot. I haven't actually tried doing this so I'm not sure there isn't some corner case it can't handle, so if Kevin or Korey could comment that would be helpful. Also, check_interrupts probably should be renamed checkInterrupts to match the style of the other function names. 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
Re: [m5-dev] g++ 4.3
On Sep 8, 2008, at 8:19 PM, nathan binkert wrote: As usual the gnu guys are out to make our life easier. I've more or less got things working with 4.3, but there are a couple of issues we need to sort out. I'll also need people to compile M5 on as many systems as possible to make sure that my changes don't break things. (I'll commit the patches in a day or so) 1) G++ now complains about lack of parenthesis in expressions with combinations of operators that are commonly screwed up. We can disable the warning with -Wno-parentheses and ignore the issue. I generally feel that people should know their order of operations, but with so many people hacking, maybe it's worth it to fix them and enable the warning. Examples a b || c d===(a b) || (c d) a b - c ===a (b - c) I even went so far as to print out order of operation lists and post them on everyones monitor. However, I suppose the parenthesis are acceptable. I think that is probably better than disabling the warning. I know one I've messed up before is ?: and that tends to lead to very bizarre errors. 2) hash_map is now deprecated and people are supposed to use unordered_map which will be in the next C++ standard. Unfortunately, it's not too easy to provide an adapter between the two without using #define. We can ignore the error for now with -Wno-deprecated, but we're going to have to bite the bullet at some point when hash_map is really moved. To top things off, if you use unordered_map, you have to set --std=c++0x or --std=gnu++0x. I'm inclined to disable the warning, and just do whatever magic is necessary when things finally break, but the downside of that is when they do break, it might be harder to keep older versions of compilers working if we don't have some sort of adapter. We already have a #define for the hashmap namespace. I don't see a huge problem with another one. So hash_map is deprecated and you don't get unordered_map without --std==c++0x? How annoying. The only way I can see to check in the code if it's a c++0x compile is __GXX_EXPERIMENTAL_CXX0X__ which doesn't seem particularly portable. I think I'm with you that disabling the warning is probably the best thing to do at this point and see where things shake out in a revision or two. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: style: Remove non-leading tabs everywhere they ...
run expand on the patch files before trying to apply them... Everything should work fine. Ali On Sep 10, 2008, at 4:44 PM, [EMAIL PROTECTED] wrote: I really hope this isn't going to make applying all my patches significantly harder... Gabe Quoting Ali Saidi [EMAIL PROTECTED]: changeset 3af77710f397 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=3af77710f397 description: style: Remove non-leading tabs everywhere they shouldn't be. Developers should configure their editors to not insert tabs diffstat: 69 files changed, 427 insertions(+), 682 deletions(-) configs/common/ Benchmarks.py | 17 src/arch/alpha/ aout_machdep.h | 21 src/arch/alpha/ floatregfile.hh |1 src/arch/alpha/ ipr.cc | 53 -- src/arch/alpha/ ipr.hh | 54 +- src/arch/alpha/ isa_traits.hh |4 src/arch/alpha/linux/ linux.cc | 16 src/arch/alpha/linux/ linux.hh | 14 src/arch/alpha/ miscregfile.hh |4 src/arch/alpha/ osfpal.cc | 193 ++- src/arch/alpha/ pagetable.hh|8 src/arch/alpha/ regfile.hh |1 src/arch/alpha/ system.cc |2 src/arch/alpha/tru64/ tru64.cc | 16 src/arch/alpha/tru64/ tru64.hh | 14 src/arch/mips/ isa_traits.hh|4 src/arch/mips/linux/ linux.cc | 16 src/arch/mips/linux/ linux.hh | 14 src/arch/mips/regfile/ regfile.hh |6 src/arch/mips/ system.cc|2 src/arch/mips/ tlb.hh |2 src/arch/sparc/linux/ linux.cc | 16 src/arch/sparc/linux/ linux.hh | 14 src/arch/sparc/ miscregfile.hh | 22 src/arch/sparc/ regfile.hh |1 src/arch/sparc/solaris/ solaris.cc | 18 src/arch/sparc/solaris/ solaris.hh | 10 src/arch/sparc/ sparc_traits.hh |1 src/arch/x86/isa/insts/general_purpose/ cache_and_memory_management.py |4 src/arch/x86/isa/insts/general_purpose/data_conversion/ ascii_adjust.py |2 src/arch/x86/isa/insts/general_purpose/ load_segment_registers.py |4 src/arch/x86/isa/insts/general_purpose/ system_calls.py |2 src/arch/x86/linux/ linux.hh| 14 src/base/ crc.cc|1 src/base/ inifile.hh|1 src/base/loader/ coff_symconst.h| 12 src/base/stats/ flags.hh|9 src/cpu/ base_dyn_inst.hh |1 src/cpu/checker/ cpu_impl.hh|2 src/cpu/memtest/ memtest.hh |2 src/cpu/o3/alpha/ dyn_inst.hh |1 src/cpu/o3/mips/ dyn_inst.hh|1 src/cpu/ simple_thread.cc |1 src/cpu/ static_inst.hh | 16 src/dev/alpha/ access.h | 14 src/dev/ etherdump.cc |8 src/dev/mips/ access.h | 16 src/dev/ ns_gige.hh |3 src/dev/ pcireg.h | 11 src/kern/linux/ linux.hh| 28 - src/kern/ operatingsystem.hh|1 src/kern/solaris/ solaris.hh| 22 src/kern/tru64/ mbuf.hh | 33 - src/kern/tru64
Re: [m5-dev] changeset in m5: style: Remove non-leading tabs everywhere they ...
we've hacked on remote_gdb so much that preserving the tabs wouldn't really help. Ali On Sep 10, 2008, at 4:48 PM, [EMAIL PROTECTED] wrote: Also I notice some of these are changes to the *bsd copyrights on some files, for instance the remote_gdbs. We probably shouldn't change those. Gabe Quoting Ali Saidi [EMAIL PROTECTED]: changeset 3af77710f397 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=3af77710f397 description: style: Remove non-leading tabs everywhere they shouldn't be. Developers should configure their editors to not insert tabs diffstat: 69 files changed, 427 insertions(+), 682 deletions(-) configs/common/ Benchmarks.py | 17 src/arch/alpha/ aout_machdep.h | 21 src/arch/alpha/ floatregfile.hh |1 src/arch/alpha/ ipr.cc | 53 -- src/arch/alpha/ ipr.hh | 54 +- src/arch/alpha/ isa_traits.hh |4 src/arch/alpha/linux/ linux.cc | 16 src/arch/alpha/linux/ linux.hh | 14 src/arch/alpha/ miscregfile.hh |4 src/arch/alpha/ osfpal.cc | 193 ++- src/arch/alpha/ pagetable.hh|8 src/arch/alpha/ regfile.hh |1 src/arch/alpha/ system.cc |2 src/arch/alpha/tru64/ tru64.cc | 16 src/arch/alpha/tru64/ tru64.hh | 14 src/arch/mips/ isa_traits.hh|4 src/arch/mips/linux/ linux.cc | 16 src/arch/mips/linux/ linux.hh | 14 src/arch/mips/regfile/ regfile.hh |6 src/arch/mips/ system.cc|2 src/arch/mips/ tlb.hh |2 src/arch/sparc/linux/ linux.cc | 16 src/arch/sparc/linux/ linux.hh | 14 src/arch/sparc/ miscregfile.hh | 22 src/arch/sparc/ regfile.hh |1 src/arch/sparc/solaris/ solaris.cc | 18 src/arch/sparc/solaris/ solaris.hh | 10 src/arch/sparc/ sparc_traits.hh |1 src/arch/x86/isa/insts/general_purpose/ cache_and_memory_management.py |4 src/arch/x86/isa/insts/general_purpose/data_conversion/ ascii_adjust.py |2 src/arch/x86/isa/insts/general_purpose/ load_segment_registers.py |4 src/arch/x86/isa/insts/general_purpose/ system_calls.py |2 src/arch/x86/linux/ linux.hh| 14 src/base/ crc.cc|1 src/base/ inifile.hh|1 src/base/loader/ coff_symconst.h| 12 src/base/stats/ flags.hh|9 src/cpu/ base_dyn_inst.hh |1 src/cpu/checker/ cpu_impl.hh|2 src/cpu/memtest/ memtest.hh |2 src/cpu/o3/alpha/ dyn_inst.hh |1 src/cpu/o3/mips/ dyn_inst.hh|1 src/cpu/ simple_thread.cc |1 src/cpu/ static_inst.hh | 16 src/dev/alpha/ access.h | 14 src/dev/ etherdump.cc |8 src/dev/mips/ access.h | 16 src/dev/ ns_gige.hh |3 src/dev/ pcireg.h | 11 src/kern/linux/ linux.hh| 28 - src/kern/ operatingsystem.hh|1 src/kern/solaris/ solaris.hh| 22 src/kern/tru64/ mbuf.hh
Re: [m5-dev] another microcode design decision
From a quick read it sounds like option 2 would be better, cleaner, and more extensible. In reality other than Alpha all ISAs have some microcoded instructions. I don't see a reason not to deal with microops as first class operations. Ali On Sep 14, 2008, at 5:19 PM, Gabe Black wrote: The more I look at this, the more it seems like there needs to be a way to discard the current macroop and start executing out of the ROM as the instruction itself. From a practical perspective, this would be more efficient than constantly checking where a microop should come from on every fetchMicroop call. The microop would come from the right place all the time. Second, it simplifies control flow to the ROM. Right now, the ROM and the regular microops live in the same micropc address space, and they're distinguished by putting the ROM at high addresses. This is a problem since the micropc branch microop only supports an 8 bit immediate value for a new absolute micropc. Even if it was relative, that would mean -all- ROM targets had to be within 255 microops of the combination micropc space which wouldn't work out very well. Third, it's more like the actual hardware where the combinational macroop does a little bit to either do the whole instruction or get out of the way, and then the ROM takes over and does it's thing. Fourth, this makes the problem of handling faults without an actual macroop easier, since it might work out that you can just go to the ROM directly. I'm not sure how well this will work out when it's all said and done, but it is an attractive idea. This does mean, however, that the problems of caching microops that have been specialized to the environment of the original instruction, operand size, blah blah, are still there. It's still going to be hard to keep track of them in a sensible way. In a real machine this is easier since you're microops are really microop templates which are then specialized for their context. Also, it means there would need to be a new mechanism in the decoder which would allow the macroops to switch themselves out for a ROM when needed. I've been toying with two ideas for how to make this happen. The first is that there would actually be two decoders. The first would be a decoder which would go to either a stream of microops actually encoded in 1s and 0s, or bring in a stream of 1s and 0s from an address space external to the CPU, aka an actual ROM. The other decoder would go from that to a series of actual microop StaticInsts which would get processed by the remainder of the CPU. I don't like this very much because it has a lot of overhead and would complicate things for ISAs that don't want to use it. The other idea would be to make the microcode ROM a first class citizen in the CPU, as apposed to a conceptual entity in the X86 microcode stuff, and to add a function to the threadcontext which would change the mode of the decoder (or whatever else is splitting out microops from macroops) to start using the ROM instead. I'd love to hear what other people think about this, so please don't hesitate to let me know. I realize my explanation might be hard to follow without being as familiar with this stuff as I am (or maybe because I didn't explain it well?), so if you'd like any clarification or a longer explanation please let me know that too. Gabe Gabe Black wrote: In addition to needing a way to get -to- the microcode in the ROM, another issue to work out is how the microops in the ROM are represented, constructed, and returned to the decoder. An important decision that that hinges on is whether or not microops in the ROM will be specialized for the operand size, address size, target registers, etc. of the originating instruction like combinationally generated microops are. In a real system they would be. For the interrupt entering microcode this shouldn't be a concern since the process is basically independent of any particular instruction or mode of operation, except at the global level. In other words, you do something different enough in each mode to have its own implementation, but each implementation works in only one way. The key difference this makes is whether or not the microops can be generated once and kept around forever, or if a new StaticInst needs to be generated for every different environment the microops are executed in. Assuming the microops are specialized, which is the more useful, realistic and difficult option, several other questions come up. The first is exactly how the ROM, which I'm envisioning making a static member of the base macroop class, will generate the microops it returns to the macroop/decoder. Unlike the case of macroops which statically allocate their microops at construction and store them in an array, the ROM will need to have many versions of the same microop around
Re: [m5-dev] CPUID implementation
I kind of ran into a similar thing with sparc. There is configuration code that needed to inform the system about the speed/size/type of various objects. It would be good to have a C++ interface to easily query the object tree to be able to make those determinations. Ali On Sep 20, 2008, at 9:42 AM, Steve Reinhardt wrote: If it's that complicated, why not just do it in C++ inside of M5, and have a special microop that just calls that function and lets it do the dirty work? I don't think performance fidelity is an issue here, and even if it were, we could always just make that single microop take longer. Steve On Sat, Sep 20, 2008 at 12:50 AM, Gabe Black [EMAIL PROTECTED] wrote: Now that I'm making the branch microop always use a fixed absolute micropc, the only place I wasn't already using it, the CPUID instruction, needs to change. The problem is, as things are implemented, it really has to be able to compute it's target. The CPUID instruction basically queries a mostly but not completely static pool of information about the CPU it's run on. For instance, it can tell you the size of various caches, what version the CPU is, who the manufacturer was, what instruction extensions are supported (that's partially where the info in /proc/cpuinfo comes from), blah blah blah. It's not completely static for two reasons. First, sometimes certain extensions are implemented in only some modes. I believe some CPUs turn off the bits of instructions that won't work in the current mode, although I'm not sure of that and I think it's done inconsistently among processors. Second, I believe Intel now allows you to tamper with the values returned by CPUID in order to allow a virtualized guest to query freely and not see capabilities that wouldn't work or that it shouldn't use. Right now, my implementation of CPUID does a little munging on the function code, which specifies what information you want, and then goes into what is essentially a big case statement/computed branch that puts the right values in the right registers and then returns. As I mentioned, since I'll no longer be able to do computed branches, this will no longer work. There are lots of other limitations too like having lots of microops to function as a basic lookup table, and the fact that the information is static and completely unconfigurable. For instance, the cache would always reported as the same size, and if some benchmark tried to use that value to behave in a certain way, it wouldn't do what it was supposed to. What I'm thinking I'd want to do is one of two things. Either the CPUID instruction should do a series of loads out of an actual lookup ROM/RAM somewhere outside of the CPU, or there could be a CPUID device which would allow it to respond in intelligent ways depending on the CPU mode, for instance. I'm favoring sticking a ROM in the memory system somewhere. Also, I'd like to put in some sort of configuration interface that would allow the configs to program in what CPUID should say if it needs to reflect the actual hardware or someone wants to add a new function, for instance. What do you guys think? 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: SCons: Update compare_versions() to ignore trai...
changeset e82da424c28f in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=e82da424c28f description: SCons: Update compare_versions() to ignore trailing charecters in versions. diffstat: 0 files changed ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] IsOn using a vector
You're talking about replacing return flags[t]; with a space optimized bit vector? I imagine it would help performance some if for no other reason that the trace flags would fit is a single cache block rather than spanning multiple as they do now. Ali On Sep 23, 2008, at 2:42 AM, Gabe Black wrote: I just finished stepping through some code having to do with PCs in simple CPU, and I noticed that not printing DPRINTFs is actually a fairly involved process, considering that you're not actually doing anything. Part of the issue, I think, is that whether or not a traceflag is on is stored in a vector of Bools. Since the size of the vector won't change often (ever?) would it make sense to just make it a char [] and use something like the following? flags[t 3] (1 (t 3)); I realize when you've got tracing on you're not going for blazing speed in the first place, but if it's easy to tighten it up a bit that's probably a good idea. The other possibility is that it's actually not doing a whole lot but calling through a bunch of functions gdb stops at one at a time. That would look like a lot of work to someone stepping through with gdb but could be just as fast. 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
Re: [m5-dev] ISA specific decoder state
On Sep 23, 2008, at 9:28 PM, Steve Reinhardt wrote: I believe it's impossible fault on a microop in the middle of a macroop and then resume where you left off in the middle of the macroop flow. If you fault you will roll back to the state at the beginning of the macroop and then on resuming from the fault you either have to reexecute the macroop from the start or skip it entirely. So it seems like the two cases where you're in the middle of a macroop flow and you end the macroop are either (1) the final, specially marked microop of the normal flow hits retire or (2) a microop causes a fault and the whole macroop is discarded and the fault handler is invoked. Interrupts don't count because you'd never take an interrupt in the middle of a macroop. I think x86s string copy instruction is a case where you have to be able to take an fault (tlb) in the middle of the micro-op and then resume. Otherwise it would be possible to prevent the machine from making forward progress with a string copy that spanned more pages than the tlb holds. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Stable
I could go either way. If it forced us to just get it done in 2 or 3 days then it would be worth it. Otherwise, we should push it off, but not too far. Ali On Sep 26, 2008, at 11:51 PM, nathan binkert wrote: Do you want to hold off on letting a stable out for this stuff? I'd say that we need to get stable done to allow things into the tree, and we can try to make this a part of the next stable release which we can target as 2.0. Nate I think high on the list needs to be a clean-up of the statistics in models. Some are fine, most exist but their precise meaning (mostly in the CPU and cache models) isn't clear, a few might be wrong, and some don't exist, but they need to (bus and bridge). I don't the the statistics are presently any worse than they are in stable, however I do think we should spend some time working on them in the near term and call that 2.0. I'll volunteer to take care of the bus and the bridge. Ali On Sep 26, 2008, at 16:41, nathan binkert [EMAIL PROTECTED] wrote: Ok, now that kevin has fixed the O3 problems that we've had, what's left? 1) I've got a couple more outstanding changes that get GCC 4.3 fully functional 2) I'd like to update all regressions so there are no differences. Anything else? Someone else willing to do the leg work to announce everything? Nate ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Confusing MIPS code
Unless Korey can come up with a fix by tomorrow, I vote to put in a panic() (not an assert) so we can create a stable release that works with gcc 4.3. Ali On Sep 24, 2008, at 9:43 AM, nathan binkert wrote: oh i think I see now... This shadow set code and DSP/MT was done by myself and some of the MIPS guys... Anyway, the issue is probably that the value for NumShadowSets or something is set to 0 or a wrong value causing the bad access. Well, if you look at the code in isa_traits.hh, NumShadowRegSets is multiplied by NumIntArchRegs, whereas in decoder.isa, something is being multipled by NumIntRegs (which is the total number of regs). So, my guess is that the rdpgpr and wrpgrp instructions are implemented incorrectly. Are there any other mips regression tests anywhere? Right now, we only have hello world, and that's not exactly going to provide coverage. I'll see if I can look into it... But this is an actual compile-time error? I must be using a previous g++... It's a warning in gcc 4.3 (and a good one). Thanks, Nate ___ 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] changeset in m5: Cleanup m5term changes with Nate's comments.
changeset 6be5ac0eb1ea in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6be5ac0eb1ea
description:
Cleanup m5term changes with Nate's comments.
diffstat:
1 file changed, 4 deletions(-)
util/term/term.c |4
diffs (48 lines):
diff -r 29cd33ac16cb -r 6be5ac0eb1ea util/term/term.c
--- a/util/term/term.c Wed Oct 01 16:27:52 2008 -0400
+++ b/util/term/term.c Wed Oct 01 16:37:49 2008 -0400
@@ -155,16 +155,15 @@
if (nfd == -1)
return;
-FD_ZERO(read_fds);
-
-FD_SET(wfd, read_fds);
-FD_SET(nfd, read_fds);
max_fd = nfd + 1;
-timeout.tv_sec = 1;
-timeout.tv_usec = 0;
+while (1) {
+FD_ZERO(read_fds);
+FD_SET(wfd, read_fds);
+FD_SET(nfd, read_fds);
+timeout.tv_sec = 1;
+timeout.tv_usec = 0;
-while (1) {
n = select(max_fd, read_fds, NULL, NULL, timeout);
if (n 0) {
close(nfd);
@@ -174,7 +173,7 @@
if (n == 0) {
if (read(nfd, buf, 0) 0)
return;
-goto setup_select;
+continue;
}
if (read(nfd, buf, 0) 0)
@@ -218,12 +217,6 @@
return;
}
}
-setup_select:
-FD_ZERO(read_fds);
-FD_SET(wfd, read_fds);
-FD_SET(nfd, read_fds);
-timeout.tv_sec = 1;
-timeout.tv_usec = 0;
} // while
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Output: Verify output files are open after open...
changeset 5e1863e9afa2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5e1863e9afa2
description:
Output: Verify output files are open after opening them.
diffstat:
2 files changed, 1 insertion(+), 1 deletion(-)
src/base/stats/text.cc |1 -
src/sim/serialize.cc |1 +
diffs (42 lines):
diff -r 6be5ac0eb1ea -r 5e1863e9afa2 src/base/stats/text.cc
--- a/src/base/stats/text.ccWed Oct 01 16:37:49 2008 -0400
+++ b/src/base/stats/text.ccThu Oct 02 12:46:57 2008 -0400
@@ -107,7 +107,8 @@
mystream = false;
stream = _stream;
-assert(valid());
+if (!valid())
+fatal(Unable to open output stream for writing\n);
}
void
@@ -118,13 +119,14 @@
mystream = true;
stream = new ofstream(file.c_str(), ios::trunc);
-assert(valid());
+if (!valid())
+fatal(Unable to open statistics file for writing\n);
}
bool
Text::valid() const
{
-return stream != NULL;
+return stream != NULL stream-good();
}
void
diff -r 6be5ac0eb1ea -r 5e1863e9afa2 src/sim/serialize.cc
--- a/src/sim/serialize.cc Wed Oct 01 16:37:49 2008 -0400
+++ b/src/sim/serialize.cc Thu Oct 02 12:46:57 2008 -0400
@@ -405,6 +405,8 @@
string cpt_file = dir + Checkpoint::baseFilename;
ofstream outstream(cpt_file.c_str());
time_t t = time(NULL);
+if (!outstream.is_open())
+fatal(Unable to open file %s for writing\n, cpt_file.c_str());
outstream // checkpoint generated: ctime(t);
globals.serialize(outstream);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] unhalting CPU
I'm pretty sure that is the way it works right now, since the alpha quiesce instruction works in a similar fashion. Ali On Oct 8, 2008, at 3:52 AM, Gabe Black wrote: I'm at the point where a timer interrupt needs to wake the CPU out of its idle thread. The idle thread uses a hlt instruction to suspend itself, and that ends up as a call to halt() on the exec context. I'm not sending interrupts through the older post, clear, etc., so I don't know if the CPU realizes it has some work to do and should stop being halted. I added a call to activate() in the interrupt object invoke method, but I don't think that'll help because the CPU's not checking its interrupts. What I probably need to do is to make the interrupts object call that function, but for that I'd need a way to get at the CPU it's part of, and know what thread to wake up. What's the right way to go about this? 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] stable
I just tried to compile m5 on a fc9 machine and it didn't work We shouldn't push stable until I get that fixed... Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] stable
It's the mysql version string in compare versions. I thought I fixed it, but I'm looking at it now... Ali On Oct 8, 2008, at 4:09 PM, nathan binkert wrote: That's odd. I thought I had done that. What compiler is it? What swig, etc? On Wed, Oct 8, 2008 at 1:01 PM, Ali Saidi [EMAIL PROTECTED] wrote: I just tried to compile m5 on a fc9 machine and it didn't work We shouldn't push stable until I get that fixed... Ali ___ 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
[m5-dev] changeset in m5: Scons: Update compare_versions() to ignore trai...
changeset d8b246a665c1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d8b246a665c1
description:
Scons: Update compare_versions() to ignore trailing charecters after an
int. This is a fix for a mysql version number that includes a (E.g. 5.0.51a)
diffstat:
0 files changed
diffs (12 lines):
diff -r 664630aaf316 -r d8b246a665c1 SConstruct
--- a/SConstructTue Oct 07 00:53:25 2008 -0400
+++ b/SConstructWed Oct 08 18:34:19 2008 -0400
@@ -91,7 +91,7 @@
if isinstance(v, (list,tuple)):
return v
elif isinstance(v, str):
-return map(int, v.split('.'))
+return map(lambda x: int(re.match('\d+', x).group()), v.split('.'))
else:
raise TypeError
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] stable
I just pushed a fix I wrote it and I thought I had committed it, but apparently not. Ali On Oct 8, 2008, at 6:18 PM, Ali Saidi wrote: It's the mysql version string in compare versions. I thought I fixed it, but I'm looking at it now... Ali On Oct 8, 2008, at 4:09 PM, nathan binkert wrote: That's odd. I thought I had done that. What compiler is it? What swig, etc? On Wed, Oct 8, 2008 at 1:01 PM, Ali Saidi [EMAIL PROTECTED] wrote: I just tried to compile m5 on a fc9 machine and it didn't work We shouldn't push stable until I get that fixed... Ali ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] m5sim.org
The hardware for m5sim.org was just updated. Sorry about the downtime, everything that could have gone wrong did. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] removing hwrei from the CPU models
I'm fairly certain you broke the O3 cpu for Alpha FS with this change. The TLB returns an access violation on a superpage access when the palcode does a hwrei to entSys from callpal_callsys. Something is preventing the mode bit from being set and the call reads a stale value resulting in an access. The first mtpr sets the mode bit, however, the fault occurs on the rei even though it shouldn't. Ali 4519995215872: testsys.switch_cpus T0 : @__bss_start+2199024826436 : call_pal 0x83: IntAlu : 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+1 : andr35,8,r24 : IntAlu : D=0x0008 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+5 : hw_mfprIPR(0x153),r22 : IprAccess : D=0xfc000790c000 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+9 : beqr24,0x4721 : IntAlu : 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+13 : hw_mfprIPR(0x149),r12 : IprAccess : D=0xfc311340 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+17 : hw_mtprr31,IPR(0x201) : IprAccess : D=0x 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+21 : hw_mtprr31,IPR(0x10f) : IprAccess : D=0x 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+25 : bisr31,r31,r35 : IntAlu : D=0x 4519995217041: testsys.switch_cpus T0 : @Call_Pal_Callsys+29 : hw_mfprIPR(0x10b),r23 : IprAccess : D=0x02198d58 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+33 : hw_mtprr30,IPR(0x152) : IprAccess : D=0x00011f813b70 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+37 : ldar30,-48(r22): IntAlu : D=0xfc000790bfd0 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+41 : stqr29,16(r30) : MemWrite : D=0x022309e0 A=0xfc000790bfe0 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+45 : stqr24,0(r30) : MemWrite : D=0x0008 A=0xfc000790bfd0 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+49 : stqr23,8(r30) : MemWrite : D=0x02198d58 A=0xfc000790bfd8 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+53 : hw_mtprr12,IPR(0x10b) : IprAccess : D=0xfc311340 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+57 : hw_mfprIPR(0x156),r29 : IprAccess : D=0xfc7a0900 4519995217208: testsys.switch_cpus T0 : @Call_Pal_Callsys+61 : hw_rei f54 : IntAlu : 4519995401075: testsys.switch_cpus T0 : @Trap_Iaccvio+1 : nop (bisr31,r31,r31) : No_OpClass : 4519995401075: testsys.switch_cpus T0 : @Trap_Iaccvio+5 : sll r35,60,r39 : IntAlu : D=0x 4519995401075: testsys.switch_cpus T0 : @Trap_Iaccvio+9 : hw_mtpr r31,IPR(0x10f) : IprAccess : D=0x 4519995401075: testsys.switch_cpus T0 : @Trap_Iaccvio+13 : bis r35,r31,r36 : IntAlu : D=0x On Aug 24, 2008, at 8:14 PM, Gabe Black wrote: I'm making a patch which is supposed to remove hwrei from the cpu models, and it seems to work. One thing that makes me a little nervous, though is that ozone is doing something with locks that the other CPUs aren't. I was hoping the regressions would help me figure out what the deal was with that, but I see we don't have any Alpha O3 FS regressions. I'm pretty sure I heard that should work, so maybe we should have some regressions for it? 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
Re: [m5-dev] cpu vs thread vs contexts
cpuId/contextId Some other comments to throw in the mix: How does this affect switch-over and sampling? Does each unique cpu in the system have a different id? (e.g. If you start with two timing cpus (0,1) and then switch to two details cpus (2,3) would you have statistics for cpus 2,3?) I think the answer is you would. Are we ok with that? One other point, while cpuid 0 is specified by the python, when the thread contexts are created I believe that each cpu is given a unique id in registerContext(). Ali On Oct 24, 2008, at 6:20 PM, Lisa Hsu wrote: what do we all like better, cpuID/contextID, or cpuId/contextId? lisa On Fri, Oct 24, 2008 at 6:07 PM, nathan binkert [EMAIL PROTECTED] wrote: The BIOS identifies all of the CPUs to the OS, but the arrangement is deduced by the OS I believe. Nate 2008/10/24 Lisa Hsu [EMAIL PROTECTED]: where does this reporting to linux happen? On Fri, Oct 24, 2008 at 5:53 PM, nathan binkert [EMAIL PROTECTED] wrote: The OS interface to that doesn't work that way. Linux for example treats all threads and cores and such as different CPUs, it just knows that certain CPUs share certain resources. i.e. it uses one global id and just has extra knowledge about how things interact in the scheduler. So, each global context ID should be reported as a separate CPU to linux. Any actual coreID (maybe that's a better name) or cpuID or threadID would be only used in the simulator Nate On Fri, Oct 24, 2008 at 2:50 PM, Korey Sewell [EMAIL PROTECTED] wrote: I do think a thread ID per core is necessary as you need to give OS's the ability to assign to a specific thread in a core and not treat all SMT cores as a separate CPU in every case. On Fri, Oct 24, 2008 at 5:47 PM, nathan binkert [EMAIL PROTECTED] wrote: I'd say that a globally unique contextID is critical. A threadID that is per core can of course be created if necessary, but I bet that in most instances, we can just pass pointers around. Nate I mostly agree with this, except that it might be tricky to use the context ID t index into a vector of thread contexts when the numbering doesn't start over for each CPU. Other than that it looks like we're strictly getting closer to the right answer at least. Gabe Quoting Lisa Hsu [EMAIL PROTECTED]: yes, that's what i mean. believe it or not, right now if you run se.py -n4, all four cpus get cpuId = 0 (regardless of which cpu type you use). talk about broken. and from now on, getCpuId() should pretty much only be used for things like stats, or as a secondary identifier, the primary thing to care about is the HW context ID. On Fri, Oct 24, 2008 at 4:51 PM, Korey Sewell [EMAIL PROTECTED] wrote: Are you saying make a distinction between the cpu ID and the actual hardware context ID? This is something definitely needed. I think this is what you describe below... I'm seeing something where there is a: getCpuId() and a getContext() function. On a 2-way SMT system with 1 CPU... process0-getCpuId() = 0 process0-getContext() = 0 process1-getCpuId() = 0 process1-getContext() = 1 but with a 2-CPU system , No-SMT... process0-getCpuId() = 0 process0-getContext() = 0 process1-getCpuId() = 1 process1-getContext() = 1 and finally, a 2-way SMT, 2-cpu system... process0-getCpuId() = 0 process0-getContext() = 0 process1-getCpuId() = 0 process1-getContext() = 1 process2-getCpuId() = 1 process2-getContext() = 2 process3-getCpuId() = 1 process3-getContext() = 3 Is this what you describe, by all means all systems go! 2008/10/24 Lisa Hsu [EMAIL PROTECTED]: Hi All, In case you haven't guessed it, I'm hacking on M5 once again. I've noticed recently that there is a big hot mess when it comes to identification mechanisms for CPUs, threads, and contexts. Alternately all contexts are assumed to be separate CPUs (which is wrong when there is SMT), vs times when CPUs are CPUs and threads are subsets of certain CPUs such that a system can have names like CPU0,T0; CPU,T1; CPU1,T0; CPU1,T1, etc. I talked about it with Steve today and here's what I propose, let me know if you object. All CPUs with have an ID, but this will not be a primary context identification mechanism. In other words, in many places where tc-getCpuId() is used in order to index into a threadContexts vector, it will be changed so that tc-getIdentifier() will give back something unique across the system. The primary context identification mechanism will be a system-wide context id-value. That
[m5-dev] changeset in m5: BATCH: Run as, ar, and ranlib with BATCH_CMD so...
changeset 96614cd66f76 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=96614cd66f76 description: BATCH: Run as, ar, and ranlib with BATCH_CMD so that they execute on the batch hosts, not local host. diffstat: 1 file changed, 1 insertion(+), 2 deletions(-) SConstruct |3 +-- diffs (17 lines): diff -r da86e00f87a0 -r 96614cd66f76 SConstruct --- a/SConstructThu Oct 23 16:49:17 2008 -0400 +++ b/SConstructSun Oct 26 14:45:47 2008 -0400 @@ -369,8 +369,11 @@ # Do this after we save setting back, or else we'll tack on an # extra 'qdo' every time we run scons. if env['BATCH']: -env['CC'] = env['BATCH_CMD'] + ' ' + env['CC'] -env['CXX'] = env['BATCH_CMD'] + ' ' + env['CXX'] +env['CC'] = env['BATCH_CMD'] + ' ' + env['CC'] +env['CXX']= env['BATCH_CMD'] + ' ' + env['CXX'] +env['AS'] = env['BATCH_CMD'] + ' ' + env['AS'] +env['AR'] = env['BATCH_CMD'] + ' ' + env['AR'] +env['RANLIB'] = env['BATCH_CMD'] + ' ' + env['RANLIB'] if sys.platform == 'cygwin': # cygwin has some header file issues... ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression --scratch all
My last commit fixed the bug that has been plaguing the sunday regressions for a while now. All the regressions passed but parser/x86 and I'm still pretty confident that there is something non- deterministic in the x86 architecture code that is causing this to happen. Ali On Oct 26, 2008, at 12:59 AM, Cron Daemon wrote: scons: *** [build/ALPHA_SE/libm5_fast.a] Error 1 scons: *** [build/ALPHA_FS/libm5_fast.a] Error 1 scons: *** [build/MIPS_SE/libm5_fast.a] Error 1 scons: *** [build/SPARC_SE/libm5_fast.a] Error 1 scons: *** [build/SPARC_FS/libm5_fast.a] Error 1 * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/long/70.twolf/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/long/10.mcf/x86/linux/simple-atomic passed. Reading the dictionary files: * * build/X86_SE/tests/fast/long/20.parser/x86/linux/simple-atomic FAILED! * build/X86_SE/tests/fast/long/00.gzip/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/long/60.bzip2/x86/linux/simple-atomic passed. See /z/m5/regression/regress-2008-10-26-03:00:01 for details. ___ 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] semantics of translating unaligned accesses
I think I must be missing something. How are x86 unaligned accesses handled now? 1 unaligned access - 3 aligned accesses that are combined? What chops them into piece? microcode? Some other means? The issue is that an access could span a page boundary so half of it could be in the TLB while the other half might not? Ali On Oct 27, 2008, at 2:58 PM, Gabe Black wrote: I injured my eye the other day and had some visitors from out of town, so I've been out of commission for the last several days. Now that I'm mostly back in the saddle, I've started working on getting the simple timing CPU working under x86. It's been going smoothly, but one issue that's come up is how the semantics of translating unaligned accesses works. In the atomic cpu, the pieces of aligned data that are composed into the final result are translated one at a time, and if any of them fault the fault is returned to the caller. In the timing CPU that doesn't fit as well since there's a delay between when the access is requested and when the first pieces of data will come back. What could happen is that either the entire access is translated at the start and it's the responsibility of the TLB to report any problems it may have up front, or the pieces are pre-translated all at once and then fed out one at a time as packets. The first approach is a little cleaner conceptually because the TLB is translating what the program actually asked for, but it's potentially harder to implement because the TLB has to do the alignment itself and check for accesses crossing regions with different properties. My preference would be to pre-translate all the chunks, but since this has the potential to affect other ISAs, I thought it was a good idea to ask for opinions. What do you guys think? 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
Re: [m5-dev] semantics of translating unaligned accesses
I still don't get what is doing the cutting into pieces? Is it done by the CPU? or does the cpu execute two instructions to fill portions of a register? Ali On Oct 27, 2008, at 6:19 PM, Gabe Black wrote: I think so, if I'm understanding you right. I looked in the manuals, and in the version of Intel's that I have in chapter 7.1, the following operations are guaranteed atomic: 486+ reading or writing a byte reading or writing a word aligned on a 16 bit boundary reading or writing a doubleword aligned on a 32 bit boundary Pentium+ Reading or writing a quadword on a 64 bit boundary 16 bit access to uncached memory locations that fit within a 32-bit data bus P6+ Unaligned 16, 32, and 64 bit accesses to cached memory that fit within a cache line And then the CPU is supposed to automatically lock for the following: xchg instruction that references memory setting the busy flag of a task descriptor updating segment descriptors updating page directory and page table entries acknowledging interrupts So it looks like, ignoring supporting the LOCK signal and prefix and the various system level resource atomic updates, if we split normal accesses across cache lines we're ensuring all the atomicity Intel does. The only tricky part is if something about the translation changes halfway through an instruction, but I don't think there are any guarantees about what's supposed to happen then anyway. Gabe Steve Reinhardt wrote: OK... so if we have to have the ability to lock a block in the cache for the duration of the instruction, then how those blocks get in there wrt TLB accesses is moot? That sounds plausible to me. Just want to make sure that if there is an interaction that we don't design something now that we have to redesign later to deal with it. Steve On Mon, Oct 27, 2008 at 5:56 PM, Gabe Black [EMAIL PROTECTED] wrote: I think (but I'm not sure) that the lock prefix applied to certain instructions makes each of several accesses they do atomic, and that otherwise the CPUs can't count on anything being atomic, so for x86 at least atomicity is a larger, separate problem. I'm not sure about that though. I'll see if I can find anything in the manuals. Gabe Steve Reinhardt wrote: There's also the possibility that these accesses could be atomic, right? On Mon, Oct 27, 2008 at 5:33 PM, Gabe Black [EMAIL PROTECTED] wrote: In the atomic simple CPU, they're broken up across the CPU's peers blocksize aligned boundaries by the CPU and done as x different accesses, usually 1 or 2. There may be some weird case were it's more than 2, but I can't think of any off the top of my head. The CPU then composites the results into a single value and sends it back to the instruction that performed the read. The problem with doing it all at once is from crossing page boundaries, and also crossing block boundaries in the cache/whatever else is connected to the d cache port. Gabe Ali Saidi wrote: I think I must be missing something. How are x86 unaligned accesses handled now? 1 unaligned access - 3 aligned accesses that are combined? What chops them into piece? microcode? Some other means? The issue is that an access could span a page boundary so half of it could be in the TLB while the other half might not? Ali On Oct 27, 2008, at 2:58 PM, Gabe Black wrote: I injured my eye the other day and had some visitors from out of town, so I've been out of commission for the last several days. Now that I'm mostly back in the saddle, I've started working on getting the simple timing CPU working under x86. It's been going smoothly, but one issue that's come up is how the semantics of translating unaligned accesses works. In the atomic cpu, the pieces of aligned data that are composed into the final result are translated one at a time, and if any of them fault the fault is returned to the caller. In the timing CPU that doesn't fit as well since there's a delay between when the access is requested and when the first pieces of data will come back. What could happen is that either the entire access is translated at the start and it's the responsibility of the TLB to report any problems it may have up front, or the pieces are pre-translated all at once and then fed out one at a time as packets. The first approach is a little cleaner conceptually because the TLB is translating what the program actually asked for, but it's potentially harder to implement because the TLB has to do the alignment itself and check for accesses crossing regions with different properties. My preference would be to pre-translate all the chunks, but since this has the potential to affect other ISAs, I thought it was a good idea to ask for opinions. What do you guys think? Gabe ___ m5-dev mailing list
Re: [m5-dev] [PATCH] Libelf: Append options to CCFLAGS for warning free libelf compile instead of deleting CCFLAGS. Should fix 64bit OS X compile problem
Clint,
Does this patch fix your building problem?
Thanks,
Ali
On Oct 28, 2008, at 6:13 PM, Ali Saidi wrote:
# HG changeset patch
# User Ali Saidi [EMAIL PROTECTED]
# Date 1225242801 14400
# Node ID 93eb7f6185172f31eb7bf8d6bec459a5a1d36065
# Parent b44dd45bd604fd12892de07245c060499728830b
Libelf: Append options to CCFLAGS for warning free libelf compile
instead of deleting CCFLAGS. Should fix 64bit OS X compile problem.
diff --git a/ext/libelf/SConscript b/ext/libelf/SConscript
--- a/ext/libelf/SConscript
+++ b/ext/libelf/SConscript
@@ -88,7 +88,7 @@
ElfFile('libelf_msize.c')
m4env = env.Copy()
-del m4env['CCFLAGS']
+m4env.Append(CCFLAGS=['-Wno-pointer-sign', '-Wno-implicit'])
del m4env['CPPPATH']
# If we have gm4 use it
___
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
