[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing 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. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level passed. * build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/inorder-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed. * build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed. * build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed. * build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/inorder-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing passed. * build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby passed. *
Re: [gem5-dev] Review Request 2499: mem: Clean up packet data allocation
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2499/ --- (Updated Nov. 26, 2014, 10:05 a.m.) Review request for Default. Repository: gem5 Description (updated) --- Changeset 10572:ca0ba71c37f9 --- mem: Clean up packet data allocation This patch attempts to make the rules for data allocation in the packet explicit, understandable, and easy to verify. The constructor that copies a packet is extended with an additional flag alloc_data to enable the call site to explicitly say whether the newly created packet is short-lived (a zero-time snoop), or has an unknown life-time and therefore should allocate its own data (or copy a static pointer in the case of static data). The tricky case is the static data. In essence this is a copy-avoidance scheme where the original source of the request (DMA, CPU etc) does not ask the memory system to return data as part of the packet, but instead provides a pointer, and then the memory system carries this pointer around, and copies the appropriate data to the location itself. Thus any derived packet actually never copies any data. As the original source does not copy any data from the response packet when arriving back at the source, we must maintain the copy of the original pointer to not break the system. We might want to revisit this one day and pay the price for a few extra memcpy invocations. All in all this patch should make it easier to grok what is going on in the memory system and how data is actually copied (or not). Diffs (updated) - src/mem/cache/cache_impl.hh dd04eb06ad42 src/mem/cache/mshr.cc dd04eb06ad42 src/mem/packet.hh dd04eb06ad42 Diff: http://reviews.gem5.org/r/2499/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2499: mem: Clean up packet data allocation
On Nov. 25, 2014, 10:11 p.m., Nilay Vaish wrote: src/mem/packet.hh, line 884 http://reviews.gem5.org/r/2499/diff/1/?file=42571#file42571line884 We need better explanation here. What do you mean by nature of copying static pointers into forwarded packets? I have added far more elaborate comments to dataStatic and dataDynamic to explain what is going on. - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2499/#review5540 --- On Nov. 26, 2014, 10:05 a.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2499/ --- (Updated Nov. 26, 2014, 10:05 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10572:ca0ba71c37f9 --- mem: Clean up packet data allocation This patch attempts to make the rules for data allocation in the packet explicit, understandable, and easy to verify. The constructor that copies a packet is extended with an additional flag alloc_data to enable the call site to explicitly say whether the newly created packet is short-lived (a zero-time snoop), or has an unknown life-time and therefore should allocate its own data (or copy a static pointer in the case of static data). The tricky case is the static data. In essence this is a copy-avoidance scheme where the original source of the request (DMA, CPU etc) does not ask the memory system to return data as part of the packet, but instead provides a pointer, and then the memory system carries this pointer around, and copies the appropriate data to the location itself. Thus any derived packet actually never copies any data. As the original source does not copy any data from the response packet when arriving back at the source, we must maintain the copy of the original pointer to not break the system. We might want to revisit this one day and pay the price for a few extra memcpy invocations. All in all this patch should make it easier to grok what is going on in the memory system and how data is actually copied (or not). Diffs - src/mem/cache/cache_impl.hh dd04eb06ad42 src/mem/cache/mshr.cc dd04eb06ad42 src/mem/packet.hh dd04eb06ad42 Diff: http://reviews.gem5.org/r/2499/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/#review5552 --- I thought the style guide said there were supposed to be spaces around operators and assignments, or am I missing something? - Andreas Hansson On Nov. 23, 2014, 7:25 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/ --- (Updated Nov. 23, 2014, 7:25 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10560:b66945a370f9 --- config: Get rid of some extra spaces around default arguments. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2523/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2521: ps2: Support translating left and right ALT keys.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2521/#review5553 --- Ship it! The keyword needs updating, for the rest it looks fine. - Andreas Hansson On Nov. 22, 2014, 1:36 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2521/ --- (Updated Nov. 22, 2014, 1:36 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10558:22cf82509e55 --- ps2: Support translating left and right ALT keys. This is used primarily for VNC. Diffs - src/dev/ps2.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2521/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2520: x86: i8042: Add VNC keyboard input support.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/#review5554 --- src/dev/x86/i8042.cc http://reviews.gem5.org/r/2520/#comment4981 for (auto k : keys) bufferData(k, 1) I would suggest x86, dev as the keyword(s) - Andreas Hansson On Nov. 22, 2014, 1:32 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/ --- (Updated Nov. 22, 2014, 1:32 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10556:76e90695e93b --- x86: i8042: Add VNC keyboard input support. This fixes up and fleshes out the keyboard model within the i8042 so that it can return keyboard input realistically enough to satisfy the kernel. One notable change was to turn off the convertScanCodes bit. That bit basically enables a compatibility mode which makes the keyboard return scancodes from set 1 which the XT computer used. We want to turn off that translation so that we get scancode set 2, the standard set which was used by the AT computer. That's also what the existing X11 keycode = scancode function developed for ARM returns. Diffs - src/dev/x86/i8042.hh 6317351a288c0349c5855c7431bc1eeade61605c src/dev/x86/i8042.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2520/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
On Nov. 26, 2014, 10:45 a.m., Andreas Hansson wrote: I thought the style guide said there were supposed to be spaces around operators and assignments, or am I missing something? I don't think the style guide says, or at least not that I see. I may be tending to the style we use at work. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/#review5552 --- On Nov. 23, 2014, 7:25 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/ --- (Updated Nov. 23, 2014, 7:25 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10560:b66945a370f9 --- config: Get rid of some extra spaces around default arguments. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2523/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2520: x86: i8042: Add VNC keyboard input support.
On Nov. 26, 2014, 10:49 a.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 261 http://reviews.gem5.org/r/2520/diff/1/?file=42720#file42720line261 for (auto k : keys) bufferData(k, 1) What is this sorcery? :-) Seriously though, what's this from? Does gcc 0.1 or whatever minimum version we support handle that? - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/#review5554 --- On Nov. 22, 2014, 1:32 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/ --- (Updated Nov. 22, 2014, 1:32 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10556:76e90695e93b --- x86: i8042: Add VNC keyboard input support. This fixes up and fleshes out the keyboard model within the i8042 so that it can return keyboard input realistically enough to satisfy the kernel. One notable change was to turn off the convertScanCodes bit. That bit basically enables a compatibility mode which makes the keyboard return scancodes from set 1 which the XT computer used. We want to turn off that translation so that we get scancode set 2, the standard set which was used by the AT computer. That's also what the existing X11 keycode = scancode function developed for ARM returns. Diffs - src/dev/x86/i8042.hh 6317351a288c0349c5855c7431bc1eeade61605c src/dev/x86/i8042.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2520/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2520: x86: i8042: Add VNC keyboard input support.
On Nov. 26, 2014, 10:49 a.m., Andreas Hansson wrote: src/dev/x86/i8042.cc, line 261 http://reviews.gem5.org/r/2520/diff/1/?file=42720#file42720line261 for (auto k : keys) bufferData(k, 1) Gabe Black wrote: What is this sorcery? :-) Seriously though, what's this from? Does gcc 0.1 or whatever minimum version we support handle that? c++ 11 And yes, gcc 4.6 supports range-based for loops. Welcome to the future...if you are so inclined :-) - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/#review5554 --- On Nov. 22, 2014, 1:32 p.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2520/ --- (Updated Nov. 22, 2014, 1:32 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10556:76e90695e93b --- x86: i8042: Add VNC keyboard input support. This fixes up and fleshes out the keyboard model within the i8042 so that it can return keyboard input realistically enough to satisfy the kernel. One notable change was to turn off the convertScanCodes bit. That bit basically enables a compatibility mode which makes the keyboard return scancodes from set 1 which the XT computer used. We want to turn off that translation so that we get scancode set 2, the standard set which was used by the AT computer. That's also what the existing X11 keycode = scancode function developed for ARM returns. Diffs - src/dev/x86/i8042.hh 6317351a288c0349c5855c7431bc1eeade61605c src/dev/x86/i8042.cc 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2520/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
On Nov. 26, 2014, 10:45 a.m., Andreas Hansson wrote: I thought the style guide said there were supposed to be spaces around operators and assignments, or am I missing something? Gabe Black wrote: I don't think the style guide says, or at least not that I see. I may be tending to the style we use at work. I could be wrong on this one. Steve, Ali, what are your thoughts? - Andreas --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/#review5552 --- On Nov. 23, 2014, 7:25 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/ --- (Updated Nov. 23, 2014, 7:25 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10560:b66945a370f9 --- config: Get rid of some extra spaces around default arguments. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2523/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
On Nov. 26, 2014, 10:45 a.m., Andreas Hansson wrote: I thought the style guide said there were supposed to be spaces around operators and assignments, or am I missing something? Gabe Black wrote: I don't think the style guide says, or at least not that I see. I may be tending to the style we use at work. Andreas Hansson wrote: I could be wrong on this one. Steve, Ali, what are your thoughts? Just to make sure we're all on the same page, I removed the spaces here because these are default values for arguments. My brain might have just pattern matched and applied a rule for named function arguments in python we use at work, but, unless there's a policy against it, I still like the way it looks in this case. For other uses of = and other operators I think there should definitely be spaces. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/#review5552 --- On Nov. 23, 2014, 7:25 a.m., Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2523/ --- (Updated Nov. 23, 2014, 7:25 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10560:b66945a370f9 --- config: Get rid of some extra spaces around default arguments. Diffs - configs/common/FSConfig.py 6317351a288c0349c5855c7431bc1eeade61605c Diff: http://reviews.gem5.org/r/2523/diff/ Testing --- Thanks, Gabe Black ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] KVM broken on x86 due to changeset 1bd64b294fe4
I just ran into some issues with kvm on x86. It seems like changeset 1bd64b294fe4 (x86: add LongModeAddressSize function to cpuid) breaks Linux running in kvm. It seems like the offending change makes cpuid report the virtual and physical address length as 255 bits, which clearly doesn't make sense. I can't justify spending any time on it, so could someone else have a quick look? I'd suggest just reverting the patch for now unless someone else has a better suggestion. //Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] KVM broken on x86 due to changeset 1bd64b294fe4
I already fixed it. The change should be checked in, I think. Gabe On Nov 26, 2014 5:52 AM, Andreas Sandberg via gem5-dev gem5-dev@gem5.org wrote: I just ran into some issues with kvm on x86. It seems like changeset 1bd64b294fe4 (x86: add LongModeAddressSize function to cpuid) breaks Linux running in kvm. It seems like the offending change makes cpuid report the virtual and physical address length as 255 bits, which clearly doesn't make sense. I can't justify spending any time on it, so could someone else have a quick look? I'd suggest just reverting the patch for now unless someone else has a better suggestion. //Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] KVM broken on x86 due to changeset 1bd64b294fe4
Thanks! I should have checked the upstream commit log. //Andreas On 26/11/14 13:54, Gabe Black via gem5-dev wrote: I already fixed it. The change should be checked in, I think. Gabe On Nov 26, 2014 5:52 AM, Andreas Sandberg via gem5-dev gem5-dev@gem5.org wrote: I just ran into some issues with kvm on x86. It seems like changeset 1bd64b294fe4 (x86: add LongModeAddressSize function to cpuid) breaks Linux running in kvm. It seems like the offending change makes cpuid report the virtual and physical address length as 255 bits, which clearly doesn't make sense. I can't justify spending any time on it, so could someone else have a quick look? I'd suggest just reverting the patch for now unless someone else has a better suggestion. //Andreas -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2523: config: Get rid of some extra spaces around default arguments.
On Wed, Nov 26, 2014 at 4:30 AM, Gabe Black via gem5-dev gem5-dev@gem5.org wrote: Just to make sure we're all on the same page, I removed the spaces here because these are default values for arguments. My brain might have just pattern matched and applied a rule for named function arguments in python we use at work, but, unless there's a policy against it, I still like the way it looks in this case. For other uses of = and other operators I think there should definitely be spaces. I'm a little surprised to see that there's no mention of spacing around operators on the wiki page. Of course, we've been enforcing spacing around operators (including assignment operators) anyway, and we should update the style guide to reflect that. I, at least, have also been treating '=' differently when used to bind default parameter values, and consider spaces there to be at best optional if not discouraged, though we don't have a hard rule against them. I see that the Google Python style does though: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Whitespace I'd be happy to follow the Google style guide on this and get rid of spaces around '=' for default parameters. They also ban spaces for calls using keyword arguments, which I think we also generally follow, but probably not consistently either. I'd say if we're going to follow Google here we should go all the way and do it for both cases. I would also say that, if we're going to ban spaces for default parameters, we should make this apply to C++ as well as Python for consistency. Interestingly, Google doesn't have this policy, because their C++ style guide generally disallows default parameters in C++ to begin with: http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Default_Arguments Just to put a stake in the ground, I added the following two bullets under http://gem5.org/Coding_Style#Spacing: - *one* space around binary operators (+, -, , , etc.) including assignment operators (=, +=, etc.) - *no* space around '=' when used in parameter/argument lists, either to bind default parameter values (in Python or C++) or to bind keyword arguments (in Python) I'm happy to edit/remove them if there's disagreement, but I figured this would give something concrete and concise to discuss. Steve ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] KvmCPU Behaviour
Hi Andreas, Sorry for the late reply, I have missed your email. I will investigate more the issues with memory controller refresh events and let you know what I find out. Best regards, Alex ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
