Are you talking about just x86?
Nate
On Mon, Feb 9, 2009 at 1:19 PM, Gabriel Michael Black
wrote:
> I have a patch in my queue which, for reasons I can get into if people
> are interested, prevents fetching in the simple CPU while in the
> middle of a macroop. A side effect of this is that ben
changeset 50fb2cb40609 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=50fb2cb40609
description:
scons: Don't build the intermediate static library unless explicitly
requested.
This means that similar to libm5_fast.so, you need to explicitly build
build/A
Feb 09 20:10:14 2009 -0800
@@ -27,6 +27,7 @@
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# Authors: Steve Reinhardt
+# Nathan Binkert
###
#
@@ -63,25 +64,55
changeset 780dd1bead5c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=780dd1bead5c
description:
copyright: This file need not have had the more restrictive copyright.
diffstat:
1 file changed, 9 insertions(+), 36 deletions(-)
src/arch/x86/SConsopts | 45 +
Hi Developers,
I just wanted to let everyone know that I pushed a change that will
move the minimum version of SCons forward to 0.98.1. This release is
less than a year old, but it prepares us for upcoming fatal errors for
removed features while also allowing me to work on some significant
improv
> changeset 09ab46bfa914 in /z/repo/m5
> details: http://repo.m5sim.org/m5?cmd=changeset;node=09ab46bfa914
> description:
>InOrder: Import new inorder CPU model from MIPS.
>This model currently only works in MIPS_SE mode, so it will take some
> effort
>to clean it up and ma
> Just one little nit to pick: this function definition here should be in
> static_inst.cc and not static_inst.hh. It certainly doesn't need to be
> inlined for performance reasons, and since it's virtual it won't get inlined
> anyway, so there's no point in cluttering the header file with it.
Th
> I'll give the short version here: MIPS was implemented ot use the MT ISA
> extension
> which requires the ability to read/write registers from other threads. I
> designed the register file
> to be on size fits all. It can be instantiated multiple times as a
> per-thread register file (Simple-CPU)
changeset 5645632d594c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5645632d594c
description:
style
diffstat:
2 files changed, 63 insertions(+), 47 deletions(-)
src/cpu/static_inst.cc | 43 --
src/cpu/static_inst.hh | 67 +++
USED 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.
+#
+# Authors: Nathan Binkert
+
+import os
+import sys
+
+from
>Hi everybody. I can't contribute to M5's x86 support right now
> because I'm still blocked on supporting TLB misses correctly. Until
> that's dealt with, all of my patches will stay in my queue behind it and
> none of them will make it into the head. If Nate, Steve, etc. could
> please help fi
changeset 8007803be77a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8007803be77a
description:
scons: clean up the main SConstruct file more.
Add some features to read_command so it works a little bit better
Clean up the mercurial checks.
Filter
esh processors every time, but that is, of course, not a general
> solution.
>
>- Clint
>
> On Jan 6, 2009, at 6:02 PM, nathan binkert wrote:
>
>> I feel like I'm missing some context with this patch (though I will
>> admit to not following the mailing list very clos
>> I don't get a holiday Monday... bummer. I'm free pretty much all day
>> though. I'm also free Tue afternoon and Wed afternoon exc. 2:30-3.
>> Tue/Wed evenings are bad for me.
> Tuesday and Wednesday afternoons wouldn't be great for me since I'd
> probably have to leave work to attend, but a p
> OK, maybe I spoke too soon... zizzer is running ubuntu hardy, and the scons
> package there is at 0.97. Should I whack the ubuntu package and install from
> scons.org, or is there a reasonable way to backport the 0.98 package from
> intrepid? If someone else wants to handle this I'd be glad
> I'll look at it, but it does raise the concern that everything but the
> latest releases of OSes will need a custom package to get to Scons > .
> 98.1
I thought that was clear from my e-mails. It is honestly very easy to
get a compliant SCons.
Nate
___
I really appreciate the help!
> As far as location, I agree src is the wrong place... how about under util,
> like util/scons or util/sconshelp?
That also doesn't seem to fit for me, but if a top level directory is
the wrong place, util is the best. I still think I like buildlib at
the top better
>> > As far as location, I agree src is the wrong place... how about under
>> > util,
>> > like util/scons or util/sconshelp?
>> That also doesn't seem to fit for me, but if a top level directory is
>> the wrong place, util is the best. I still think I like buildlib at
>> the top better,
>
> What'
> My "toy" example of this is say I want to read a integer register from an
> instruction. I could either go:
> (1) inst->threadContext->readIntReg()
> or
> (2) inst->cpu->readIntReg()
>
> In the threadContext object, there is just some redundant call to
> cpu->readIntReg() anyway. So you end up ca
Are you running the very latest code? I made some changes a few days
ago, since Ali changed it a few weeks ago.
Nate
On Sat, Feb 14, 2009 at 8:32 PM, Gabe Black wrote:
>I'm getting the following from scons:
>
> Mercurial binary cannot be found, unfortunately this means that we
> cannot ea
at 5:43 PM, Gabe Black wrote:
>>
>> Yes.
>>
>> nathan binkert wrote:
>> > Are you running the very latest code? I made some changes a few days
>> > ago, since Ali changed it a few weeks ago.
>> >
>> > Nate
>> >
>> >
changeset 98f6215dffce in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=98f6215dffce
description:
SCons: Fix read_command so it can properly deal with command strings
diffstat:
1 file changed, 3 insertions(+)
SConstruct |3 +++
diffs (13 lines):
diff -r 8007803be77a
changeset 67a6ea624776 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=67a6ea624776
description:
traceflags: fix --trace-help
diffstat:
3 files changed, 19 insertions(+), 18 deletions(-)
src/python/m5/main.py | 13 -
src/python/m5/trace.py
Just looking at the output seems to indicate that you've done
something funny with your mercurial setup. Do you have mq in both
your .hgrc file and in /etc/mercurial?
Nate
2009/2/16 Korey Sewell :
> Hey all,
> I am currently unable to build any CPU Model successfully after the scons
> update..
> Also, could someone explain how the idleCycle count compares to the kernel
> stat "mode_ticks_idle"? Obviously, one is in cycles and the other one is in
> ticks, but they seem to be capturing two different behaviors.
mode_ticks_idle is idle as reported by the kernel. That is, the
cycles where
>In x86 there are at least three different ways to call a system
> call, int $0x80, sysenter, and syscall. In 64 bit mode I think syscall
> is pretty much guaranteed to be there so glibc uses it directly, or at
> least that's been my experience. For 32 bit x86, though, sysenter, the
> preferred
> If #2 didnt exist, then that would make more sense to me. That would make an
> instruction HAVE to use the threadContext interface to access any CPU
> facilities. That would also remove the CPU pointer from the instruction
> object as well.
>
> If that were the solution, I would be OK with it, be
> It's only a few instructions to push three registers on the stack, use
> the appropriate instruction, pop those three, and return. All together
> it's 11 bytes.
I don't think one can claim copyright on 11 bytes.
Nate
___
m5-dev mailing list
m5-dev@m
> I'm not sure I all the way understand why the register file shouldnt be
> defined in the ISA...
>
> I could see maybe there being one standard integer and floating point
> register file thats totally generic however, the system/miscellaneous
> registers are pretty ISA dependent so those register
works there?
>
> 2009/2/17 Korey Sewell
>>
>> Hmmm...Dont know what's going on here.. I just reinstalled mercurial with
>> no luck...
>>
>> Can someone post the contents of their build/ALPHA_SE/python/m5/defines.py
>> file so I can see the differenc
gt; hgext.mq =
> patchbomb =
> style = /home/ksewell/m5/util/style.py
>
> So for some reason, adding patch-queue to the repo just kills the
> build for me...
>
> On Tue, Feb 17, 2009 at 3:18 PM, nathan binkert wrote:
>> I think that the problem is that you've got st
changeset e9f9c0f7e5f0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e9f9c0f7e5f0
description:
events: Make trace events happen at the right priority.
Also, while we're at it, remember that priorities are in the Event class
and add a disable method to di
Hi Steve/everyone,
right now, we have code in src/python/swig. I'm thinking that for the
swig stuff, we should distribute the .i files along with the code they
wrap. Mostly this means that swig code goes in sim. I'm thinking
about this because I was going to add a .i file or two and wanted to
d
> What a coincidence... I've never really looked at this code before about 4
> hours ago. Brad and I were wondering where Stats::dump() gets called, and I
> poked around and found src/python/swig/stats.i, and the first thing I thought
> was "shouldn't this really go in src/base/stats?" I was g
> A long time ago we talked about making some sort of hierarchy for
> SimObjects so that they could mirror the namespaces in C++. That way I
> wouldn't have to put IntelMP at the beginning of the name of all the
> Intel MP table objects. In that case we'd want the python
> package/directory structu
> diff -r 7a74edaa8741 -r b6e4240c46e4 src/arch/alpha/floatregfile.hh
> --- a/src/arch/alpha/floatregfile.hhSun Feb 15 23:43:39 2009 -0800
> +++ b/src/arch/alpha/floatregfile.hhFri Feb 20 09:06:11 2009 -0500
> @@ -48,6 +48,13 @@ getFloatRegName(RegIndex)
> return "";
> }
>
> +const int
> 1) not sure why the mt.hh file didnt get added to the patch, but it
> should be there
I think the real problem is that you're adding an mt.hh, but only for
mips. That doesn't work so well with the switching directory code.
___
m5-dev mailing list
m5-d
> Ok. I figured it was something like that. Rather than use those in
> place in O3, we might want to try to put them in a neutral spot and
> then make them available for both. It would probably be confusing for
> someone working on o3 if they ended up changing in order accidentally
> in the process
SE,
+ * 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 D
changeset cba4b5495d7b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=cba4b5495d7b
description:
stats: fix text printout for distributions
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/base/stats/text.cc |2 +-
diffs (12 lines):
diff -r c810b7d4383d
changeset 1db89432381b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1db89432381b
description:
stats: clean up the statistics unittest
diffstat:
1 file changed, 55 insertions(+), 50 deletions(-)
src/unittest/stattest.cc | 105 -
changeset 9775f70fbe66 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9775f70fbe66
description:
stats: move the limits stuff into the types.hh file
diffstat:
2 files changed, 3 insertions(+), 3 deletions(-)
src/base/statistics.hh |3 ---
src/base/stats/types.hh |
changeset 02e5bc7ca9ba in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=02e5bc7ca9ba
description:
stats: reorganize how parameters are stored and accessed.
diffstat:
4 files changed, 209 insertions(+), 197 deletions(-)
src/base/statistics.cc | 24 ++-
src/base/statisti
PLARY, 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 OT
cs.hh
--- a/src/base/statistics.hhMon Feb 23 12:04:52 2009 -0800
+++ b/src/base/statistics.hhMon Feb 23 12:22:15 2009 -0800
@@ -26,7 +26,6 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Authors: Nathan Binkert
- * Erik Hallnor
*/
/** @f
changeset c810b7d4383d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c810b7d4383d
description:
stats: cleanup static stats to make startup work.
This is mainly to allow the unit test to run without requiring the
standard
M5 stats from being initialized
I've never seen this happen. Which version of SCons are you using?
Are you current with all of my recent SCons changes? Is NFS or any
remote filesystem involved, etc?
Nate
On Tue, Feb 24, 2009 at 1:39 AM, Gabe Black wrote:
> I mentioned this earlier, but scons and regressions are misbehav
I've noticed that that command runs frequently when unnecessary, but
I'm surprised that it causes a problem. Are you pushing and popping
patches? Now that we're putting the repository version into the
binary, when you push and pop, this changes. I have noticed that this
runs sometimes even if yo
[Polina- We should really have these conversations on the list so
everyone can benefit from them and to give others the chance to
respond]
Hi Nate,
I am trying to get SPARC_FS to run. I am trying to run two processors
and what I have so far is the following:
Processor 0 gets activated and runs.
> diff --git a/src/arch/x86/isa/microops/ldstop.isa
> b/src/arch/x86/isa/microops/ldstop.isa
> --- a/src/arch/x86/isa/microops/ldstop.isa
> +++ b/src/arch/x86/isa/microops/ldstop.isa
> @@ -454,7 +454,7 @@
> Mem = Data;
> Base = merge(Base, EA - SegBase, addressSize);
>
Traceback (most recent call last):
> File "", line 1, in
> File "/tmp/m5/src/python/m5/main.py", line 315, in main
> e = event.create(trace.enable, Event.Trace_Enable_Pri)
> NameError: name 'Event' is not defined
>
>
> Ali
>
>
> On Feb
Can you commit?
Thanks,
Nate
On Wed, Feb 25, 2009 at 8:59 AM, Ali Saidi wrote:
> That fixed it.
> Ali
>
> On Feb 25, 2009, at 1:37 AM, nathan binkert wrote:
>
>> Sorry. It should be event.Event... Does that fix it?
>>
>> On Tue, Feb 24, 2009 at 10:27 PM, Ali
everything again.
>
> Gabe
>
> nathan binkert wrote:
>> Can you commit?
>>
>> Thanks,
>> Nate
>>
>> On Wed, Feb 25, 2009 at 8:59 AM, Ali Saidi wrote:
>>
>>> That fixed it.
>>> Ali
>>>
>>> On Feb 25, 2009, at 1:37 AM
> That's it for the first batch. The second batch will likely come tonight
> or maybe tomorrow.
Wow. It looked like you messed with some of the register stuff. How
much of that pdf document that you wrote about did you address? I only
noticed the flattening stuff, but was there more?
Nate
___
changeset 0ea37baabfb0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0ea37baabfb0
description:
quell gcc 4.3 warning
diffstat:
1 file changed, 4 insertions(+), 4 deletions(-)
src/arch/x86/tlb.cc |8
diffs (25 lines):
diff -r d4cb6394049b -r 0ea37baabfb0
I agree that this stuff is all messed up. There's threads and cpus
each which have various states that don't necessarily work with each
other. Some of the states have to do with indicating that a CPU has
nothing to do at the moment so we don't need to schedule a tick, and
some indicate the type o
gt;
> Changing things for FS breaks SE and vice-versa.
>
> Needless to say, we should probably get this straightened out and
> documented in the near future...
>
>
> On Sat, Feb 28, 2009 at 9:30 PM, nathan binkert wrote:
>> I agree that this stuff is all messed up. The
I think that Steve is the only one who both pays attention to the list
and might understand what's going on here.
Nate
On Mon, Feb 23, 2009 at 2:30 AM, Gabe Black wrote:
> I was working on getting the X86_FS working with the timing simple
> CPU as well as it does with atomic, and found that
We agreed to start to avoid using names like getfoo() and setfoo() and
instead just have the get and set function both be called foo(), and
the protected member variable should be called _foo.
If you don't mind fixing it, that'd be nice.
Nate
On Mon, Mar 2, 2009 at 7:58 AM, Korey Sewell wrote
> @@ -53,6 +53,15 @@ struct InterStageStruct {
> uint64_t nextPC;
> InstSeqNum squashedSeqNum;
> bool includeSquashInst;
> +
> + InterStageStruct()
> + {
> + size = 0;
> + mispredPC = nextPC = 0;
> + squash = branchMispredict = branchTaken = false;
> +
> The m5 binary on the disk image that we distribute doesn't support the
> pin command. You'll need to compile it yourself. Additionally, I don't
> believe libc on the disk image supports sched_setaffinity (needed by
> pin). This is something we need to fix, but it unfortunately involves
> distribu
> + int id()
> + {
> + return _id;
> + }
> +
This one should be declared const. "int id() const" ...
Please try to use const properly.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
If you want to get going quickly, you can download the scons-local
package and just stick it somewhere.
Nate
2009/3/5 Polina Dudnik :
> Yes, I am trying to figure it out right now by running it withing gdb. It is
> pretty interesting that my output only differs from yours by one line which
> is
> There are multiple benchmarks that can be run in FS mode (like
> ValStream). Where can I find a precise description of what those
> benchmarks do exactly? The reason I ask is because I would like to
> verify their behavior on SPARC_FS.
I don't know if much has been written down other than in pape
changeset 9c04119e93af in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9c04119e93af
description:
serialize: Allow floats and doubles to be serialized
diffstat:
1 file changed, 2 insertions(+)
src/sim/serialize.cc |2 ++
diffs (12 lines):
diff -r 3ca926101a5c -r 9c0
changeset 71e56052768f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=71e56052768f
description:
stats: miscellaneous cleanup
diffstat:
1 file changed, 7 insertions(+), 9 deletions(-)
src/base/statistics.hh | 16 +++-
diffs (82 lines):
diff -r 9c04119e93a
changeset 19131d568007 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=19131d568007
description:
stats: get rid of meaningless uses of virtual
diffstat:
1 file changed, 79 insertions(+), 79 deletions(-)
src/base/statistics.hh | 158 -
changeset 2c9823c60c8c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2c9823c60c8c
description:
stats: better naming of template parameters for the wrapper stuff
Parent and Child are bad names. Derived and Base are better.
diffstat:
1 file changed, 25 insertio
changeset 7674070ccc92 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7674070ccc92
description:
stats: Add a wrapper class for the information side of things.
This provides an easy way to provide the callbacks into the data side
of things from the info si
changeset 471090ec173e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=471090ec173e
description:
stats: stick the distribution's fancy parameter into the parameters
structure.
diffstat:
3 files changed, 22 insertions(+), 26 deletions(-)
src/base/statistics.hh | 23 +
changeset a4c935e9cf99 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a4c935e9cf99
description:
stats: remove the template wart left over from the ancient binning stuff
diffstat:
1 file changed, 14 insertions(+), 28 deletions(-)
src/base/statistics.hh | 42 ++
changeset 3cf8e71257e0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3cf8e71257e0
description:
stats: Fix all stats usages to deal with template fixes
diffstat:
50 files changed, 486 insertions(+), 486 deletions(-)
src/arch/alpha/kernel_stats.hh| 12
changeset 4f887be9e1b6 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4f887be9e1b6
description:
stats: clean up how templates are used on the data side.
This basically works by taking advantage of the curiously recurring
template
pattern in an intelligen
changeset 00251eb95de7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=00251eb95de7
description:
stats: create an enable phase, and a prepare phase.
Enable more or less takes the place of check, but also allows stats to
do some other configuration. Prepar
<>
Stats::Vector<>
These should now just be:
Stats::Scalar
Stats::Vector
You're simply removing the <> which was totally useless anyway.
Nate
On Thu, Mar 5, 2009 at 7:11 PM, Nathan Binkert wrote:
> changeset a4c935e9cf99 in /z/repo/m5
> details: http://repo.m5
> Here's another option: make the CPU model smart and when it sees a
> "lock" access have it keep running until it sees an "unlock" access.
> This might not be too bad if "keep running" could be implemented
> simply by doing something like a recursive tail call to tick().
There's already a big loo
I'm trying to remove duplicate statistics names, and I came upon
something in MIPS that is broken (and break some coding rules in the
process).
MIPS has something called a UTB. I'm assuming that this object is
supposed to implement a shared TLB for both instruction access and
data access. I don't
> How different are ITBs and DTBs anyway? It seems like for a UTB you'd
> want a single object that handles both ifetch and data translations
> using a common translate() method, not something that inherits from
> two different classes. E.g., why not just derive it from TLB?
The two translation f
> Right, but you could have a flag that says "ifetch" (or an
> ifetch/read/write enum in place of the read/write flag we have now) to
> control that behavior. Then the current ITB would panic on a read or
> write request, and the DTB would panic on an ifetch, but a UTB could
> handle all of the ab
> This should (knock on wood) be pretty easy to implement and I'd be happy
> to help.
Do you mind taking a detour from your current work and giving it a
shot? I'll be available to review diffs.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5s
hile it hasn't
>> caused any other problems it prevents Korey from having a UTB
>> implementation. We'd likely want to give it parameters which let you
>> independently configure it's ITB and DTB (or UTB) personalities, but
>> that should be pretty easy.
&g
> I'll keep both pointers then. I have all the non-ISA bits and X86
> converted and I'm trying to test it, but I'm running into a compile
> error in the stats stuff. Nate?
>
> cc1plus: warnings being treated as errors
> build/X86_SE/base/statistics.hh: In member function
> 'Stats::VectorDistributio
> so the solution should probably be move the ITB/DTB functions into one base
> TLB and then let a unified TLB derive off of that...correct?
I don't think so. I think the end result will be just one TLB object
(in the arch directories) derived from BaseTLB (in the sim directory).
I don't see why
> Is the following correct? This is in the BaseCPU where it sets up the
> data and instruction TLBs it's going to use and installs defaults. I'm
> suspicious that this is actually installing a particular TLB to be the
> default in all of the CPUs, or in other words all CPUs share the same
> ITB and
> Actually I take that back. That's how it would work if we used
> inheritance. The BaseTLB doesn't actually know to translate anything, so
> the UTB would provide it's own implementation directly. You'd still
> assign it to both ITB and DTB parameters.
I still don't understand why there isn't tru
> That's odd... if it doesn't work that way, I'd consider that a bug.
>
> On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black wrote:
>> I tried something like this before, and I don't think it works because
>> self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to
>> instantiate those obj
nter,
> Stats::Counter, Stats::Counter)':
> build/X86_SE/base/statistics.hh:2498: warning: converting to
> 'Stats::size_type' from 'double'
> cc1plus: warnings being treated as errors
> build/X86_SE/base/statistics.hh: In member function
> 'Sta
> I didn't directly implement that UTB part myself but I believe the mips utlb
> has some different features than a normal tlb which allows them to share one
> structure. I think that's part of their "claim to fame" so to speak...
>
> Unfortunately, I can't think of the exact mechanism right now, b
> 1. Diff the outputs and set the pass/fail status based on the result.
> 2. Declare the test's status as failed regardless of the outputs but
> consider the job of running the test as completed successfully. The
> test will not be re-run unless some dependence changes (like one that
> causes the
Actually, I did fix it, and I was waiting for regressions to run.
I'll see if they're done, and push the changes.
Nate
On Sat, Mar 7, 2009 at 2:56 PM, Gabe Black wrote:
> Any luck?
>
> nathan binkert wrote:
>> I'll try to figure this out, but I don't get it
changeset 7d75f1a525db in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7d75f1a525db
description:
build: fix errors for compilers other than g++ 4.3
diffstat:
2 files changed, 2 insertions(+), 2 deletions(-)
src/base/cp_annotate.hh |2 +-
src/base/statistics.hh |
changeset 8f374fd9a348 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8f374fd9a348
description:
scons: fix the library path stuff
diffstat:
1 file changed, 3 insertions(+), 3 deletions(-)
SConstruct |6 +++---
diffs (30 lines):
diff -r 7d75f1a525db -r 8f374fd9a348
changeset 97660425ff39 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=97660425ff39
description:
stats: cleanup text output stuff and fix mysql output
diffstat:
4 files changed, 105 insertions(+), 123 deletions(-)
src/base/statistics.hh | 37 +-
src/base/stats
changeset 1dc178e53487 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1dc178e53487
description:
stats: fix duplicate statistics names.
This generally requires providing a more meaningful name() function for
a
class.
diffstat:
4 files changed, 29 insert
changeset 5437d5f54973 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5437d5f54973
description:
tests: update tests because of changes in stat names and in the stats
package
diffstat:
26 files changed, 663 insertions(+), 619 deletions(-)
tests/long/00.gzip/ref/alpha/t
> OK, well I just unintentionally found that scons doesn't reliably
> terminate on ^C even outside of the regressions (like when compiling
> or doing the autoconf stuff) so sticking with the current plan is at
> least no worse than that.
Really? I don't recall ever really having that problem.
N
> @@ -29,10 +29,18 @@
> import os
> from os.path import isdir, isfile, join as joinpath
>
> -homedir = os.environ['HOME']
> -confdir = os.environ.get('M5_CONFIG', joinpath(homedir, '.m5'))
> +
> +confdir = os.environ.get('M5_CONFIG')
> +
> +if not confdir:
> + # HOME is not set when running re
changeset 74bc713c71ce in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=74bc713c71ce
description:
build: fix compiler warnings in g++ 3.4
diffstat:
1 file changed, 11 insertions(+), 11 deletions(-)
src/arch/x86/faults.hh | 22 +++---
diffs (60 lines):
> Seems like it would be worth setting up a slew of g++ revs on zizzer
> and running regressions under all of them, maybe on a rotating
> basis...
Yeah, I agree. Multiple revs of swig and maybe scons would be good
too. I think we should set up a separate compile everything
regression actually.
1) Anybody have any problems if I remove the last remnants of
turbolaser code that's in the TLB? We haven't had the devices in
forever and I just don't see it ever being used?
2) There's a bunch of code to make stats compatible with simplescalar
output. Can I clobber it all and use the normal M5
701 - 800 of 1984 matches
Mail list logo
