[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick

2014-07-02 Thread Cron Daemon via gem5-dev
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed. *

Re: [gem5-dev] Review Request 2141: arm: Add support for ARMv8 (AArch64 AArch32)

2014-07-02 Thread Amin Farmahini via gem5-dev
Any comments on this? Amin On Mon, Jun 30, 2014 at 6:14 PM, Amin Farmahini amin...@gmail.com wrote: Thanks Ali for the response. That makes sense. However, I faced another issue that is weird. If I set *numPhysFloatRegs* to 160, I don't get any assertion error, but the simulation does not

Re: [gem5-dev] Review Request 2304: base: fix some bugs in EthAddr

2014-07-02 Thread Anthony Gutierrez via gem5-dev
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2304/ --- (Updated July 2, 2014, 3:51 p.m.) Review request for Default. Repository: gem5

Re: [gem5-dev] Review Request 2304: base: fix some bugs in EthAddr

2014-07-02 Thread Anthony Gutierrez via gem5-dev
On July 2, 2014, 12:08 a.m., Steve Reinhardt wrote: src/base/inet.hh, line 101 http://reviews.gem5.org/r/2304/diff/1/?file=40127#file40127line101 seems like it would be more consistent with the other code to do a loop up to ETH_ADDR_LEN, but this works too. fixed - Anthony

Re: [gem5-dev] Review Request 2141: arm: Add support for ARMv8 (AArch64 AArch32)

2014-07-02 Thread Anthony Gutierrez via gem5-dev
If you just set the number of physical registers to 160 you will get a deadlock because you're making it possible for the number of instructions in flight to be greater than the number of registers available and you're rename table is filling up. 0: system.cpu.rename: [tid:0]: *Stall: RenameMap

[gem5-dev] changeset in gem5: base: fix some bugs in EthAddr

2014-07-02 Thread Anthony Gutierrez via gem5-dev
changeset 878f2f30b12d in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=878f2f30b12d description: base: fix some bugs in EthAddr per the IEEE 802 spec: 1) fixed broadcast() to ensure that all bytes are equal to 0xff. 2) fixed unicast() to

[gem5-dev] bi-mode branch predictor miss prediction rate is high

2014-07-02 Thread Zi Yan via gem5-dev
Hi, I just updated gem5-dev and got bi-mode as ARM's default branch predictor. I got mis-prediction rate (system.cpu.branchPred.condIncorrect/system.cpu.branchPred.condPredicted) ranging from 10% to 60%, whereas I saw mis-prediction rate ranging from 1% to 9% with tournament for SPEC CPU 2006

Re: [gem5-dev] bi-mode branch predictor miss prediction rate is high

2014-07-02 Thread Anthony Gutierrez via gem5-dev
This could depend on a lot of factors. How are you running the benchmarks? E.g., running SPEC 2k6's gcc to completion with the train input set in FS mode yields a 6.45% miss rate for bi-mode, while the tournament predictor yields a 7.12% miss rate. Anthony Gutierrez

Re: [gem5-dev] bi-mode branch predictor miss prediction rate is high

2014-07-02 Thread Zi Yan via gem5-dev
I get 5 100-million-instruction simpoints for each benchmark in SPEC CPU 2006 with *ref input*. I am using cross-tool arm-cortex_a15-linux-gnueabi-gcc version 4.8.2 to compile. For gcc, I got from 0.2% to 5% miss rate from tournament, but 3% to 22% miss rate from bi-mode cross all simpoints.

Re: [gem5-dev] Review Request 2292: python: Change parsing of Addr so hex values work from scripts

2014-07-02 Thread Mitch Hayenga via gem5-dev
On June 20, 2014, 2:36 a.m., Steve Reinhardt wrote: Why is Addr being parsed using toMemorySize() in the first place? That seems wrong. At least some of the places Addr is used with a size (like RealView.max_mem_size), I think the problem is that the param should really be a