[m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick

2008-08-19 Thread Cron Daemon
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-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/00.hello/alpha/linux/simple-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/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-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/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-atomic 
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/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic 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/quick/50.memtest/alpha/linux/memtest passed.

See /z/m5/regression/regress-2008-08-19-03:00:01 for details.

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] shadow parameter definitions

2008-08-19 Thread Gabe Black
I just figured out a rather annoying bug in the CPU where the 
profile event got scheduled at a totally bogus time which killed the 
simulation. The problem is that there's a profile parameter in both 
the atomic simple CPU and the base CPU. The atomic simple CPU sets it's 
version of profile at some point but the base CPU one never does. I'm 
guessing that's because the atomic CPU's definition masks the other when 
the parameter values get loaded up. Then, in the C++, if you refer to 
the profile member variable of the params struct, the hidden version 
is in scope that never got populated.

There's several different things I can see as the right thing to 
do in this situation, but I'm sure what it's doing right now isn't it. 
First, we could say this sort of thing (params overwriting each other) 
is illegal, and we throw an error when it happens. This seems the most 
reasonable since you'd probably have a hard time even setting the hidden 
version in python. The other version, which at least would prevent wild 
dangling values, would be to initialize both versions of the parameter 
according to their defaults.

Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


Re: [m5-dev] shadow parameter definitions

2008-08-19 Thread nathan binkert
There's several different things I can see as the right thing to
 do in this situation, but I'm sure what it's doing right now isn't it.
 First, we could say this sort of thing (params overwriting each other)
 is illegal, and we throw an error when it happens. This seems the most
 reasonable since you'd probably have a hard time even setting the hidden
 version in python. The other version, which at least would prevent wild
 dangling values, would be to initialize both versions of the parameter
 according to their defaults.

Rick Strong just found this bug last week, and he just committed a fix
for it.  I agree that we need to catch this, and I'm personally in
favor of raising an exception in the case where one value shadows
another.  The other option (initialize all values) would be much more
difficult and doesn't seem worth it.  Can you add a flyspray task and
assign it to me?

Thanks,
  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


Re: [m5-dev] shadow parameter definitions

2008-08-19 Thread Gabe Black
nathan binkert wrote:
There's several different things I can see as the right thing to
 do in this situation, but I'm sure what it's doing right now isn't it.
 First, we could say this sort of thing (params overwriting each other)
 is illegal, and we throw an error when it happens. This seems the most
 reasonable since you'd probably have a hard time even setting the hidden
 version in python. The other version, which at least would prevent wild
 dangling values, would be to initialize both versions of the parameter
 according to their defaults.
 

 Rick Strong just found this bug last week, and he just committed a fix
 for it.  I agree that we need to catch this, and I'm personally in
 favor of raising an exception in the case where one value shadows
 another.  The other option (initialize all values) would be much more
 difficult and doesn't seem worth it.  Can you add a flyspray task and
 assign it to me?

 Thanks,
   Nate
 ___
 m5-dev mailing list
 m5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/m5-dev
   
I must have missed that commit email, but I pulled the change and 
profile seems to be fixed. function_trace and function_trace_start have 
the same problem and weren't changed so I'll push a fix for that if 
nobody minds. The flyspray task is added.

Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev


[m5-dev] changeset in m5: CPU: Get rid of two more duplicated CPU params.

2008-08-19 Thread Gabe Black
changeset eaeed2bdf50d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=eaeed2bdf50d
description:
CPU: Get rid of two more duplicated CPU params.

diffstat:

2 files changed, 2 deletions(-)
src/cpu/simple/AtomicSimpleCPU.py |1 -
src/cpu/simple/TimingSimpleCPU.py |1 -

diffs (24 lines):

diff -r 17c0c17726ff -r eaeed2bdf50d src/cpu/simple/AtomicSimpleCPU.py
--- a/src/cpu/simple/AtomicSimpleCPU.py Mon Aug 18 10:50:58 2008 -0700
+++ b/src/cpu/simple/AtomicSimpleCPU.py Tue Aug 19 21:59:09 2008 -0700
@@ -35,8 +35,6 @@
 width = Param.Int(1, CPU width)
 simulate_data_stalls = Param.Bool(False, Simulate dcache stall cycles)
 simulate_inst_stalls = Param.Bool(False, Simulate icache stall cycles)
-function_trace = Param.Bool(False, Enable function trace)
-function_trace_start = Param.Tick(0, Cycle to start function trace)
 icache_port = Port(Instruction Port)
 dcache_port = Port(Data Port)
 physmem_port = Port(Physical Memory Port)
diff -r 17c0c17726ff -r eaeed2bdf50d src/cpu/simple/TimingSimpleCPU.py
--- a/src/cpu/simple/TimingSimpleCPU.py Mon Aug 18 10:50:58 2008 -0700
+++ b/src/cpu/simple/TimingSimpleCPU.py Tue Aug 19 21:59:09 2008 -0700
@@ -32,8 +32,6 @@
 
 class TimingSimpleCPU(BaseSimpleCPU):
 type = 'TimingSimpleCPU'
-function_trace = Param.Bool(False, Enable function trace)
-function_trace_start = Param.Tick(0, Cycle to start function trace)
 icache_port = Port(Instruction Port)
 dcache_port = Port(Data Port)
 _mem_ports = BaseSimpleCPU._mem_ports + ['icache_port', 'dcache_port']
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev