[m5-dev] interrupts interface
Since I've been poking around the Interrupts object, I've noticed we've got a lot of functions on there, and we can probably trim that down a bit. There are functions related to setting and clearing interrupts which go away when those are delivered through the memory system, although that transition will take a while and I'm not planning on it any time soon. Also, there are three functions related to getting an interrupt to process. There's check_interrupts which returns a bool of whether or not there's an interrupt waiting, getInterrupt which actually retrieves the interrupt, and updateIntrInfo which records the fact that the interrupt is about to happen in the ThreadContext. What I think will work and be a bit more streamline is to combine getInterrupt and updateIntrInfo into one function called, for instance, acceptInterrupt. This way you can check whether an interrupt is ready whenever you want without going through the overhead of actually generating it, and when you're ready to actually invoke it, you can do that all in one shot. I haven't actually tried doing this so I'm not sure there isn't some corner case it can't handle, so if Kevin or Korey could comment that would be helpful. Also, check_interrupts probably should be renamed checkInterrupts to match the style of the other function names. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick
scons: *** [build/ALPHA_SE/m5.fast] Error 1 scons: *** [build/ALPHA_FS/m5.fast] Error 1 * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. = Output differences =* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing 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/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. See /z/m5/regression/regress-2008-09-08-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Stable
how long has SMT regressions been broke? Is this a new thing? I havent looked at O3 SMT in awhile, but I would assume the O3 changes over the past year or so take my fix time way up! Is there a particular changeset or marker where we can say it broke here...? On Sat, Sep 6, 2008 at 1:25 PM, nathan binkert [EMAIL PROTECTED] wrote: What's still left to do for stable? There's the SMT regression failure. Korey or Kevin can you guys look into that so we can get this done? Is there anything else? I have stuff just waiting to get into the tree and I'm holding off for this stable release. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Stable
alright, i'll dig a little and see what's up. On Mon, Sep 8, 2008 at 10:27 AM, nathan binkert [EMAIL PROTECTED] wrote: how long has SMT regressions been broke? Is this a new thing? I havent looked at O3 SMT in awhile, but I would assume the O3 changes over the past year or so take my fix time way up! Is there a particular changeset or marker where we can say it broke here...? It hasn't been broken for all that long, and the break is just that an assertion is failing now that never used to fail. The assertion started firing when Steve changed the default latency for main memory to something longer and more realistic. I think Ali sent an e-mail a few weeks ago with the exact changeset number, but given that it's an assertion that now fails because a simple latency changed, I don't know that the changeset helps all that much. The problem is that the rest of us don't know enough to understand the assertion. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Detecting gcc
I'm trying to get thing working in gcc 4.3, so I installed a beta of intrepid ibex. The first bug was that the logic for detecting GCC is wrong in some way. How about the attached diff. It seems right for old ubuntu, new ubuntu, fedora, and my mac. Nate cxx.diff Description: Binary data ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Detecting gcc
Seems reasonable to me. Ali On Sep 8, 2008, at 6:32 PM, nathan binkert wrote: I'm trying to get thing working in gcc 4.3, so I installed a beta of intrepid ibex. The first bug was that the logic for detecting GCC is wrong in some way. How about the attached diff. It seems right for old ubuntu, new ubuntu, fedora, and my mac. Nate cxx.diff___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] g++ 4.3
As usual the gnu guys are out to make our life easier. I've more or less got things working with 4.3, but there are a couple of issues we need to sort out. I'll also need people to compile M5 on as many systems as possible to make sure that my changes don't break things. (I'll commit the patches in a day or so) 1) G++ now complains about lack of parenthesis in expressions with combinations of operators that are commonly screwed up. We can disable the warning with -Wno-parentheses and ignore the issue. I generally feel that people should know their order of operations, but with so many people hacking, maybe it's worth it to fix them and enable the warning. Examples a b || c d===(a b) || (c d) a b - c ===a (b - c) 2) hash_map is now deprecated and people are supposed to use unordered_map which will be in the next C++ standard. Unfortunately, it's not too easy to provide an adapter between the two without using #define. We can ignore the error for now with -Wno-deprecated, but we're going to have to bite the bullet at some point when hash_map is really moved. To top things off, if you use unordered_map, you have to set --std=c++0x or --std=gnu++0x. I'm inclined to disable the warning, and just do whatever magic is necessary when things finally break, but the downside of that is when they do break, it might be harder to keep older versions of compilers working if we don't have some sort of adapter. Anyone have any opinions? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] interrupts interface
I don't think this optimization will work. The reason that the get and update parts were separated was because getInterupt() is supposed to be callable without changing the interrupt/system state. If memory serves the reason for this is because there are cases where you might call get a fault multiple places interrupt + itb fault + something else and the fault priority the ISA specifies is not the order which we would generate things. The two step process allows us to fix that up. Ali On Sep 8, 2008, at 2:01 AM, Gabe Black wrote: Since I've been poking around the Interrupts object, I've noticed we've got a lot of functions on there, and we can probably trim that down a bit. There are functions related to setting and clearing interrupts which go away when those are delivered through the memory system, although that transition will take a while and I'm not planning on it any time soon. Also, there are three functions related to getting an interrupt to process. There's check_interrupts which returns a bool of whether or not there's an interrupt waiting, getInterrupt which actually retrieves the interrupt, and updateIntrInfo which records the fact that the interrupt is about to happen in the ThreadContext. What I think will work and be a bit more streamline is to combine getInterrupt and updateIntrInfo into one function called, for instance, acceptInterrupt. This way you can check whether an interrupt is ready whenever you want without going through the overhead of actually generating it, and when you're ready to actually invoke it, you can do that all in one shot. I haven't actually tried doing this so I'm not sure there isn't some corner case it can't handle, so if Kevin or Korey could comment that would be helpful. Also, check_interrupts probably should be renamed checkInterrupts to match the style of the other function names. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] g++ 4.3
On Sep 8, 2008, at 8:19 PM, nathan binkert wrote: As usual the gnu guys are out to make our life easier. I've more or less got things working with 4.3, but there are a couple of issues we need to sort out. I'll also need people to compile M5 on as many systems as possible to make sure that my changes don't break things. (I'll commit the patches in a day or so) 1) G++ now complains about lack of parenthesis in expressions with combinations of operators that are commonly screwed up. We can disable the warning with -Wno-parentheses and ignore the issue. I generally feel that people should know their order of operations, but with so many people hacking, maybe it's worth it to fix them and enable the warning. Examples a b || c d===(a b) || (c d) a b - c ===a (b - c) I even went so far as to print out order of operation lists and post them on everyones monitor. However, I suppose the parenthesis are acceptable. I think that is probably better than disabling the warning. I know one I've messed up before is ?: and that tends to lead to very bizarre errors. 2) hash_map is now deprecated and people are supposed to use unordered_map which will be in the next C++ standard. Unfortunately, it's not too easy to provide an adapter between the two without using #define. We can ignore the error for now with -Wno-deprecated, but we're going to have to bite the bullet at some point when hash_map is really moved. To top things off, if you use unordered_map, you have to set --std=c++0x or --std=gnu++0x. I'm inclined to disable the warning, and just do whatever magic is necessary when things finally break, but the downside of that is when they do break, it might be harder to keep older versions of compilers working if we don't have some sort of adapter. We already have a #define for the hashmap namespace. I don't see a huge problem with another one. So hash_map is deprecated and you don't get unordered_map without --std==c++0x? How annoying. The only way I can see to check in the code if it's a c++0x compile is __GXX_EXPERIMENTAL_CXX0X__ which doesn't seem particularly portable. I think I'm with you that disabling the warning is probably the best thing to do at this point and see where things shake out in a revision or two. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: style: This file hugely violated the M5 style.
changeset bb31ea8583d8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=bb31ea8583d8
description:
style: This file hugely violated the M5 style.
Remove a bunch of unused cruft from the interface while we're at it
diffstat:
2 files changed, 20 insertions(+), 40 deletions(-)
src/base/loader/hex_file.cc | 51 ++-
src/base/loader/hex_file.hh |9 ++-
diffs (269 lines):
diff -r bf358d99eff7 -r bb31ea8583d8 src/base/loader/hex_file.cc
--- a/src/base/loader/hex_file.cc Wed Sep 03 00:52:54 2008 -0400
+++ b/src/base/loader/hex_file.cc Mon Sep 08 18:03:52 2008 -0700
@@ -28,134 +28,109 @@
* Authors: Jaidev Patwardhan
*/
+#include cctype
+#include cstdio
#include list
#include string
-
-#include sys/types.h
-#include sys/mman.h
-#include fcntl.h
-#include stdio.h
-#include unistd.h
#include base/cprintf.hh
#include base/loader/hex_file.hh
#include base/loader/symtab.hh
-
-
#include mem/translating_port.hh
using namespace std;
-/* Load a Hex File into memory.
- Currently only used with MIPS BARE_IRON mode.
- A hex file consists of [Address Data] tuples that get directly loaded into
- physical memory. The address specified is a word address (i.e., to get the
byte address, shift left by 2)
- The data is a full 32-bit hex value.
+/*
+ * Load a Hex File into memory. Currently only used with MIPS
+ * BARE_IRON mode. A hex file consists of [Address Data] tuples that
+ * get directly loaded into physical memory. The address specified is
+ * a word address (i.e., to get the byte address, shift left by 2) The
+ * data is a full 32-bit hex value.
*/
HexFile::HexFile(const string _filename)
: filename(_filename)
{
- fp = fopen(filename.c_str(),r);
- if(fp == NULL)
-{
- panic(Unable to open %s\n,filename.c_str());
-}
-
+fp = fopen(filename.c_str(), r);
+if (fp == NULL)
+panic(Unable to open %s\n, filename.c_str());
}
HexFile::~HexFile()
{
}
-
bool
-HexFile::loadSections(Port *memPort, Addr addrMask)
+HexFile::loadSections(Port *memPort)
{
- char Line[64];
- Addr MemAddr;
- uint32_t Data;
- while(!feof(fp))
-{
- fgets(Line,64,fp);
- parseLine(Line,MemAddr,Data);
- // printf(Hex:%u\n,Data);
-
- if(MemAddr != 0)
-{
- // Now, write to memory
- memPort-writeBlob(MemAddr2,(uint8_t *)Data,sizeof(Data));
+char Line[64];
+Addr MemAddr;
+uint32_t Data;
+while (!feof(fp)) {
+fgets(Line, 64, fp);
+parseLine(Line, MemAddr, Data);
+if (MemAddr != 0) {
+// Now, write to memory
+memPort-writeBlob(MemAddr 2, (uint8_t *)Data, sizeof(Data));
}
}
return true;
}
-void HexFile::parseLine(char *Str,Addr *A, uint32_t *D)
+
+void
+HexFile::parseLine(char *Str, Addr *A, uint32_t *D)
{
- int i=0;
- bool Flag = false;
- *A = 0;
- *D = 0;
- int Digit = 0;
- unsigned Number = 0;
- /* Skip white spaces */
- while(Str[i] != '\0' Str[i]==' ')
-i++;
+int i = 0;
+bool Flag = false;
+*A = 0;
+*D = 0;
+int Digit = 0;
+unsigned Number = 0;
- /* Ok, we're at some character...process things */
- while(Str[i] != '\0')
-{
- if(Str[i]='0' Str[i]='9')
-{
- Digit=Str[i]-'0';
+/* Skip white spaces */
+while (Str[i] != '\0' Str[i]==' ')
+i++;
+
+/* Ok, we're at some character...process things */
+while (Str[i] != '\0') {
+if (Str[i] = '0' Str[i] = '9') {
+Digit = Str[i] - '0';
+} else if (Str[i] = 'a' Str[i] = 'f') {
+Digit = Str[i] - 'a' + 10;
+} else if (Str[i] = 'A' Str[i] = 'F') {
+ Digit=Str[i]-'A'+10;
+} else if (Str[i] == ' ' || Str[i] == '\n') {
+if (Number == 0)
+return;
+if (Flag == false) {
+*A = Number;
+Number = 0;
+Flag = true;
+} else {
+*D = Number;
+return;
+}
+} else {
+// Ok, we've encountered a non-hex character, cannot be a
+// valid line, skip and return 0's
+*A = 0;
+*D = 0;
+return;
}
- else if(Str[i]='a' Str[i]='f')
-{
- Digit=Str[i]-'a'+10;
-}
- else if(Str[i]='A' Str[i]='F')
-{
- Digit=Str[i]-'A'+10;
-}
- else if(Str[i] == ' ' || Str[i]=='\n')
-{
- if(Number == 0)
-return;
- if(Flag == false)
-{
- *A = Number;
- Number = 0;
- Flag = true;
-}
- else
-{
- *D = Number;
- return;
-}
-}
- else
-{
- // Ok, we've encountered a non-hex character, cannot be a valid
line, skip and return 0's
- *A = 0;
-
Re: [m5-dev] g++ 4.3
I'm in favor of ignoring the parenthesis warning. Gabe Quoting nathan binkert [EMAIL PROTECTED]: As usual the gnu guys are out to make our life easier. I've more or less got things working with 4.3, but there are a couple of issues we need to sort out. I'll also need people to compile M5 on as many systems as possible to make sure that my changes don't break things. (I'll commit the patches in a day or so) 1) G++ now complains about lack of parenthesis in expressions with combinations of operators that are commonly screwed up. We can disable the warning with -Wno-parentheses and ignore the issue. I generally feel that people should know their order of operations, but with so many people hacking, maybe it's worth it to fix them and enable the warning. Examples a b || c d===(a b) || (c d) a b - c ===a (b - c) 2) hash_map is now deprecated and people are supposed to use unordered_map which will be in the next C++ standard. Unfortunately, it's not too easy to provide an adapter between the two without using #define. We can ignore the error for now with -Wno-deprecated, but we're going to have to bite the bullet at some point when hash_map is really moved. To top things off, if you use unordered_map, you have to set --std=c++0x or --std=gnu++0x. I'm inclined to disable the warning, and just do whatever magic is necessary when things finally break, but the downside of that is when they do break, it might be harder to keep older versions of compilers working if we don't have some sort of adapter. Anyone have any opinions? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] interrupts interface
I'll buy that. Gabe Quoting Ali Saidi [EMAIL PROTECTED]: I don't think this optimization will work. The reason that the get and update parts were separated was because getInterupt() is supposed to be callable without changing the interrupt/system state. If memory serves the reason for this is because there are cases where you might call get a fault multiple places interrupt + itb fault + something else and the fault priority the ISA specifies is not the order which we would generate things. The two step process allows us to fix that up. Ali On Sep 8, 2008, at 2:01 AM, Gabe Black wrote: Since I've been poking around the Interrupts object, I've noticed we've got a lot of functions on there, and we can probably trim that down a bit. There are functions related to setting and clearing interrupts which go away when those are delivered through the memory system, although that transition will take a while and I'm not planning on it any time soon. Also, there are three functions related to getting an interrupt to process. There's check_interrupts which returns a bool of whether or not there's an interrupt waiting, getInterrupt which actually retrieves the interrupt, and updateIntrInfo which records the fact that the interrupt is about to happen in the ThreadContext. What I think will work and be a bit more streamline is to combine getInterrupt and updateIntrInfo into one function called, for instance, acceptInterrupt. This way you can check whether an interrupt is ready whenever you want without going through the overhead of actually generating it, and when you're ready to actually invoke it, you can do that all in one shot. I haven't actually tried doing this so I'm not sure there isn't some corner case it can't handle, so if Kevin or Korey could comment that would be helpful. Also, check_interrupts probably should be renamed checkInterrupts to match the style of the other function names. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
