[gem5-dev] Review Request: alpha: make hwrei a control inst
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: make hwrei a control inst this always changes the PC and is basically an impromptu branch instruction. why not speculate on this instead of always be forced to mispredict/squash after the hwrei gets resolved? The InOrder model needs this marked as isControl so it knows to update the PC after the ALU executes it. If this isnt marked as control, then it's going to force the model to check the PC of every instruction at commit (what O3 does?), and that would be a wasteful check for a very high percentage of instructions. Diffs - src/arch/alpha/isa/decoder.isa 77d12d8f7971 Diff: http://reviews.m5sim.org/r/740/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: alpha: naming for dtb faults
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: naming for dtb faults Just dfault gets confusing while debugging. Why not differentiate whether it's an access violation or page fault Diffs - src/arch/alpha/faults.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/741/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. *
Re: [gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
On 2011-06-08 22:52:15, Gabe Black wrote: I think you missed some (maybe just one) version of PC state defined in the ISAs themselves. ARM may be the only one, but you should double check to be sure. Also, for all these you could define them using ==, something like return !(*this == opc); The !(*this == opc) is interesting. If you do it that way, it's definitely more programmable for the long term since one change to the equals operator definition will propagate. But, is that way adding two extra operations there? 1 to dereference the this pointer and then another to do the NOT operation? The == operator is the more used operator but if for some reason the != operator become popular within gem5 wouldnt it be slightly slower? - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/#review1303 --- On 2011-06-08 22:46:05, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/ --- (Updated 2011-06-08 22:46:05) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpus/isa: add a != operator for pcstate Diffs - src/arch/generic/types.hh 77d12d8f7971 Diff: http://reviews.m5sim.org/r/738/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
On 2011-06-08 22:52:15, Gabe Black wrote: I think you missed some (maybe just one) version of PC state defined in the ISAs themselves. ARM may be the only one, but you should double check to be sure. Also, for all these you could define them using ==, something like return !(*this == opc); Korey Sewell wrote: The !(*this == opc) is interesting. If you do it that way, it's definitely more programmable for the long term since one change to the equals operator definition will propagate. But, is that way adding two extra operations there? 1 to dereference the this pointer and then another to do the NOT operation? The == operator is the more used operator but if for some reason the != operator become popular within gem5 wouldnt it be slightly slower? I think defining != in terms of == is much preferred for the reasons you said. The compiler should inline the == definition into != where appropriate, so the performance difference for optimized code should be somewhere between non-existent and negligible, and certainly worthwhile given how much simpler and more robust the code will be. You should just be able to define it once on the base class too which will simplify things even more. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/#review1303 --- On 2011-06-08 22:46:05, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/ --- (Updated 2011-06-08 22:46:05) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpus/isa: add a != operator for pcstate Diffs - src/arch/generic/types.hh 77d12d8f7971 Diff: http://reviews.m5sim.org/r/738/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve On Thu, Jun 9, 2011 at 12:46 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. *
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve On Thu, Jun 9, 2011 at 12:46 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed.
Re: [gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
On 2011-06-08 22:52:15, Gabe Black wrote: I think you missed some (maybe just one) version of PC state defined in the ISAs themselves. ARM may be the only one, but you should double check to be sure. Also, for all these you could define them using ==, something like return !(*this == opc); Korey Sewell wrote: The !(*this == opc) is interesting. If you do it that way, it's definitely more programmable for the long term since one change to the equals operator definition will propagate. But, is that way adding two extra operations there? 1 to dereference the this pointer and then another to do the NOT operation? The == operator is the more used operator but if for some reason the != operator become popular within gem5 wouldnt it be slightly slower? Steve Reinhardt wrote: I think defining != in terms of == is much preferred for the reasons you said. The compiler should inline the == definition into != where appropriate, so the performance difference for optimized code should be somewhere between non-existent and negligible, and certainly worthwhile given how much simpler and more robust the code will be. You should just be able to define it once on the base class too which will simplify things even more. Be really careful just defining it in the base class. It's not virtual as far as I remember, and generally speaking the subclasses add extra things to check. You could end up using the base class version and not checking everything, but it would frequently be right and could slip by pretty easily. I'm not saying it won't work, just be very careful and verify it's doing exactly what you think it is in all the ISAs one by one. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/#review1303 --- On 2011-06-08 22:46:05, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/ --- (Updated 2011-06-08 22:46:05) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpus/isa: add a != operator for pcstate Diffs - src/arch/generic/types.hh 77d12d8f7971 Diff: http://reviews.m5sim.org/r/738/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: alpha: naming for dtb faults
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/#review1310 --- This seems reasonable to me, but we should consider if the old name was the actual name given by the architecture. I'm not that familiar with Alpha so I have no idea. If it was, then you could do something like dfault (paging) and dfault (perm) or similar and preserve the old name for the sake of looking things up in a manual. - Gabe On 2011-06-08 23:25:03, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/ --- (Updated 2011-06-08 23:25:03) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: naming for dtb faults Just dfault gets confusing while debugging. Why not differentiate whether it's an access violation or page fault Diffs - src/arch/alpha/faults.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/741/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/#review1311 --- This isn't a review, just a thought on the question you're asking. If the access is speculative, is it ok to use a misspeculated pc since the instruction will be thrown out anyway? - Gabe On 2011-06-08 23:34:50, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- (Updated 2011-06-08 23:34:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: cpus/isa: add a != operator for pcstate
On 2011-06-08 22:52:15, Gabe Black wrote: I think you missed some (maybe just one) version of PC state defined in the ISAs themselves. ARM may be the only one, but you should double check to be sure. Also, for all these you could define them using ==, something like return !(*this == opc); Korey Sewell wrote: The !(*this == opc) is interesting. If you do it that way, it's definitely more programmable for the long term since one change to the equals operator definition will propagate. But, is that way adding two extra operations there? 1 to dereference the this pointer and then another to do the NOT operation? The == operator is the more used operator but if for some reason the != operator become popular within gem5 wouldnt it be slightly slower? Steve Reinhardt wrote: I think defining != in terms of == is much preferred for the reasons you said. The compiler should inline the == definition into != where appropriate, so the performance difference for optimized code should be somewhere between non-existent and negligible, and certainly worthwhile given how much simpler and more robust the code will be. You should just be able to define it once on the base class too which will simplify things even more. Gabe Black wrote: Be really careful just defining it in the base class. It's not virtual as far as I remember, and generally speaking the subclasses add extra things to check. You could end up using the base class version and not checking everything, but it would frequently be right and could slip by pretty easily. I'm not saying it won't work, just be very careful and verify it's doing exactly what you think it is in all the ISAs one by one. You're right, it doesn't work to just define it in the base class since the other functions are not virtual. So forget my comment on that one, you will have to define it in each class where == is defined. Defining != in terms of == is still the way to go though. - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/#review1303 --- On 2011-06-08 22:46:05, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/738/ --- (Updated 2011-06-08 22:46:05) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpus/isa: add a != operator for pcstate Diffs - src/arch/generic/types.hh 77d12d8f7971 Diff: http://reviews.m5sim.org/r/738/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
On 2011-06-09 11:17:24, Gabe Black wrote: This isn't a review, just a thought on the question you're asking. If the access is speculative, is it ok to use a misspeculated pc since the instruction will be thrown out anyway? Actually after briefly looking at the code, I wonder if we don't have a bigger problem here. I'm assuming that the ThreadContext struct reflects the committed state of the machine, where we really want the state relative to this in-flight instruction. Have we just been getting lucky so far? Seems like in Alpha the TLB only uses the PC to see if it's in PAL mode or not, so maybe the pipeline gets flushed when we switch in and out of PAL mode and thus there's never an inconsistency there even in O3. (Nate or Ali, can you confirm this?) Korey, can you elaborate on the kind of errors you were running into without this change? Technically I think perhaps the TLB should be using the ExecContext interface instead of the ThreadContext, but since ExecContext isn't a real object, that only works if you template the call... I wonder if we really should be using something like the ProxyThreadContext (see cpu/thread_context.hh) wrapped around a DynInst. Does that make sense? - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/#review1311 --- On 2011-06-08 23:34:50, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- (Updated 2011-06-08 23:34:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
ok, this is a bit wierd. I'm running all the tests locally and they are passing ... Even the O3 one: build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp On Thu, Jun 9, 2011 at 1:52 PM, Korey Sewell ksew...@umich.edu wrote: Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve On Thu, Jun 9, 2011 at 12:46 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. *
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
It fails for me... are you sure you've pushed everything? Have you tried it on zizzer? Steve On Thu, Jun 9, 2011 at 1:36 PM, Korey Sewell ksew...@umich.edu wrote: ok, this is a bit wierd. I'm running all the tests locally and they are passing ... Even the O3 one: build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp On Thu, Jun 9, 2011 at 1:52 PM, Korey Sewell ksew...@umich.edu wrote: Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0 774 774 +.00% system.cpu.num_func_calls 0 146 146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve On Thu, Jun 9, 2011 at 12:46 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. *
Re: [gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
On 2011-06-09 11:17:24, Gabe Black wrote: This isn't a review, just a thought on the question you're asking. If the access is speculative, is it ok to use a misspeculated pc since the instruction will be thrown out anyway? Steve Reinhardt wrote: Actually after briefly looking at the code, I wonder if we don't have a bigger problem here. I'm assuming that the ThreadContext struct reflects the committed state of the machine, where we really want the state relative to this in-flight instruction. Have we just been getting lucky so far? Seems like in Alpha the TLB only uses the PC to see if it's in PAL mode or not, so maybe the pipeline gets flushed when we switch in and out of PAL mode and thus there's never an inconsistency there even in O3. (Nate or Ali, can you confirm this?) Korey, can you elaborate on the kind of errors you were running into without this change? Technically I think perhaps the TLB should be using the ExecContext interface instead of the ThreadContext, but since ExecContext isn't a real object, that only works if you template the call... I wonder if we really should be using something like the ProxyThreadContext (see cpu/thread_context.hh) wrapped around a DynInst. Does that make sense? Steve, you're correct that entrances and exists from PAL are serialize the pipeline so it isn't an issue. The thread context is pretty much used to just read miscellaneous register. Due to them (rightly) not being renamed and updated at commit the tlb is getting non-speculative state only. Any instruction that is going to do something that needs to be visible to later instructions needs to be marked as serializing. In short, I don't think we need to change the current interface and the hwrei change is very broken. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/#review1311 --- On 2011-06-08 23:34:50, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- (Updated 2011-06-08 23:34:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: alpha: make hwrei a control inst
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/#review1315 --- You can make it a control instruction -- that shouldn't cause any issues, but making it non-serializing is nearly hopeless. HWREI changes the processor state and effects translation among other things. All PAL code instructions that exist before it in the pipe must be complete before other instructions. This is especially true since we use ev5 pal code. I'm pretty sure that o3 does inst-mispredicted() on every instruction. I'm not sure if this is any faster than first calling isControl() on it, but i doubt it. - Ali On 2011-06-08 23:15:21, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/ --- (Updated 2011-06-08 23:15:21) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: make hwrei a control inst this always changes the PC and is basically an impromptu branch instruction. why not speculate on this instead of always be forced to mispredict/squash after the hwrei gets resolved? The InOrder model needs this marked as isControl so it knows to update the PC after the ALU executes it. If this isnt marked as control, then it's going to force the model to check the PC of every instruction at commit (what O3 does?), and that would be a wasteful check for a very high percentage of instructions. Diffs - src/arch/alpha/isa/decoder.isa 77d12d8f7971 Diff: http://reviews.m5sim.org/r/740/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: alpha: naming for dtb faults
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/#review1316 --- Ship it! looks fine. - Ali On 2011-06-08 23:25:03, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/741/ --- (Updated 2011-06-08 23:25:03) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: naming for dtb faults Just dfault gets confusing while debugging. Why not differentiate whether it's an access violation or page fault Diffs - src/arch/alpha/faults.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/741/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Enabled instruction fetch pipelining.
On 2011-05-27 16:54:40, Ali Saidi wrote: I think this type of change is necessary for reasonable performance, but the implementation here does pose some issues for any ISA that uses micro-coded instructions (and faults on one). Additionally, if you look at small issue width CPUs this doesn't generally solve the problem. We've re-worked this change to fix the correctness issue and as soon as it goes through a battery of internal tests we can post it for review if that works for everyone. We've got a fixed up version that I'll post here when I have a chance. There were a few issues with micro-ops + faults + this change that are now fixed. Please don't commit this. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/718/#review1263 --- On 2011-05-24 12:01:29, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/718/ --- (Updated 2011-05-24 12:01:29) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Enabled instruction fetch pipelining. This patch is from one of our co-ops who has since finished her term, Yasuko Watanabe. I don't personally know much about it. In the end, I'll push in her name. Thanks. Diffs - src/cpu/o3/fetch.hh 54a65799e4c1 src/cpu/o3/fetch_impl.hh 54a65799e4c1 Diff: http://reviews.m5sim.org/r/718/diff Testing --- Thanks, Lisa ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Single Header File for Debug Flags
Well, I guess the recompilation tradeoff is worth the temporary annoyance of adding the specific debug flag header file everywhere. I'm also hoping that the new changes will allow us to eventually make compound flags of compound flags. The changes are already in the tree (and have been for a while). I think compound flags of compound flags should work. Nate ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: alpha: make hwrei a control inst
On 2011-06-09 15:11:58, Ali Saidi wrote: You can make it a control instruction -- that shouldn't cause any issues, but making it non-serializing is nearly hopeless. HWREI changes the processor state and effects translation among other things. All PAL code instructions that exist before it in the pipe must be complete before other instructions. This is especially true since we use ev5 pal code. I'm pretty sure that o3 does inst-mispredicted() on every instruction. I'm not sure if this is any faster than first calling isControl() on it, but i doubt it. OK thanks, does anyone else have any objections to hwrei as a control instruction? By speculate on hwrei, I meant less of the serialization aspect and more of the speculation behind that instruction. We could possibly get the hwrei correct in the BTB so it's not a 100% mispredict rate there. You are right in that it's probably negligible performance difference from checking isControl() v. inst-mispredicted(), but I got the inorder model to cache the instruction schedules now so we can basically remove that check all together. It's the difference between not calling inst-isControl() and calling it that I'm referring to as wasteful. - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/#review1315 --- On 2011-06-08 23:15:21, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/740/ --- (Updated 2011-06-08 23:15:21) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- alpha: make hwrei a control inst this always changes the PC and is basically an impromptu branch instruction. why not speculate on this instead of always be forced to mispredict/squash after the hwrei gets resolved? The InOrder model needs this marked as isControl so it knows to update the PC after the ALU executes it. If this isnt marked as control, then it's going to force the model to check the PC of every instruction at commit (what O3 does?), and that would be a wasteful check for a very high percentage of instructions. Diffs - src/arch/alpha/isa/decoder.isa 77d12d8f7971 Diff: http://reviews.m5sim.org/r/740/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: inorder/dtb: make sure DTB translate correct address
On 2011-06-09 11:17:24, Gabe Black wrote: This isn't a review, just a thought on the question you're asking. If the access is speculative, is it ok to use a misspeculated pc since the instruction will be thrown out anyway? Steve Reinhardt wrote: Actually after briefly looking at the code, I wonder if we don't have a bigger problem here. I'm assuming that the ThreadContext struct reflects the committed state of the machine, where we really want the state relative to this in-flight instruction. Have we just been getting lucky so far? Seems like in Alpha the TLB only uses the PC to see if it's in PAL mode or not, so maybe the pipeline gets flushed when we switch in and out of PAL mode and thus there's never an inconsistency there even in O3. (Nate or Ali, can you confirm this?) Korey, can you elaborate on the kind of errors you were running into without this change? Technically I think perhaps the TLB should be using the ExecContext interface instead of the ThreadContext, but since ExecContext isn't a real object, that only works if you template the call... I wonder if we really should be using something like the ProxyThreadContext (see cpu/thread_context.hh) wrapped around a DynInst. Does that make sense? Ali Saidi wrote: Steve, you're correct that entrances and exists from PAL are serialize the pipeline so it isn't an issue. The thread context is pretty much used to just read miscellaneous register. Due to them (rightly) not being renamed and updated at commit the tlb is getting non-speculative state only. Any instruction that is going to do something that needs to be visible to later instructions needs to be marked as serializing. In short, I don't think we need to change the current interface and the hwrei change is very broken. Can you rephrase this: I don't think we need to change the current interface and the hwrei change is very broken. Are you saying that the subsequent hwrei patch is not what we want or ??? I think the interface is broken and we get away with it more than it's correctly coded. We may get away with in alpha, but I would think seeding the TLB with the last committed PC rather than the current PC that needs to be translated is wrong and would at some point break the code. Steve, I think when I caught this error it was when the InOrder wasnt respecting the serializeBefore flag correctly. Thus, you get a mixup in which instruction PC needs to be translated. - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/#review1311 --- On 2011-06-08 23:34:50, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/743/ --- (Updated 2011-06-08 23:34:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- inorder/dtb: make sure DTB translate correct address The DTB expects the correct PC in the ThreadContext but how if the memory accesses are speculative? Shouldn't we send along the requestor's PC to the translate functions? Diffs - src/cpu/inorder/resources/cache_unit.cc 77d12d8f7971 Diff: http://reviews.m5sim.org/r/743/diff Testing --- Thanks, Korey ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
My local repo has this at the tip: hg tip changeset: 8342:77d12d8f7971 tag: tip user:Korey Sewell ksew...@umich.edu date:Thu Jun 09 01:34:06 2011 -0400 summary: sparc: compilation fixes for inorder and the hg outgoing tab says nothing outstanding. I have not tried this on zizzer yet, but that is the next step. On Thu, Jun 9, 2011 at 6:02 PM, Steve Reinhardt ste...@gmail.com wrote: It fails for me... are you sure you've pushed everything? Have you tried it on zizzer? Steve On Thu, Jun 9, 2011 at 1:36 PM, Korey Sewell ksew...@umich.edu wrote: ok, this is a bit wierd. I'm running all the tests locally and they are passing ... Even the O3 one: build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp On Thu, Jun 9, 2011 at 1:52 PM, Korey Sewell ksew...@umich.edu wrote: Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve On Thu, Jun 9, 2011 at 12:46 AM, Cron Daemon r...@zizzer.eecs.umich.edu wrote: * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp FAILED! * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing FAILED! * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic FAILED! * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing FAILED! scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. *
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Korey, try 'hg status'. It would list the set of files that are not being tracked. May be there is some file that should be committed and has not been. -- Nilay On Thu, 9 Jun 2011, Korey Sewell wrote: My local repo has this at the tip: hg tip changeset: 8342:77d12d8f7971 tag: tip user:Korey Sewell ksew...@umich.edu date:Thu Jun 09 01:34:06 2011 -0400 summary: sparc: compilation fixes for inorder and the hg outgoing tab says nothing outstanding. I have not tried this on zizzer yet, but that is the next step. On Thu, Jun 9, 2011 at 6:02 PM, Steve Reinhardt ste...@gmail.com wrote: It fails for me... are you sure you've pushed everything? Have you tried it on zizzer? Steve On Thu, Jun 9, 2011 at 1:36 PM, Korey Sewell ksew...@umich.edu wrote: ok, this is a bit wierd. I'm running all the tests locally and they are passing ... Even the O3 one: build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp On Thu, Jun 9, 2011 at 1:52 PM, Korey Sewell ksew...@umich.edu wrote: Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
