Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Jason Lowe-Power


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.
> 
> Jason Lowe-Power wrote:
> I see, I bet it was that I fixed some of the include orderings and got 
> that error.
> 
> I have another question, though...
> 
> I'm trying to test this out myself. I downloaded the compiler from 
> https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
> `riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
> -march=RV64I`.
> 
> When trying to run the binary I'm getting the error
> ```
> panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
>  @ tick 318000
> ```
> 
> What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py 
> with changes to use the atomic CPU instead of the timing.
> 
> Thanks for all your work!
> 
> Alec Roelke wrote:
> I have been using riscv64-unknown-elf-gcc rather than 
> riscv64-unknown-gnu-linux-gcc.  I don't know if riscv-gnu-toolchain will 
> build riscv64-unknown-elf-gcc, but you can get riscv-tools and build that, 
> and then you get riscv64-unknown-elf-gcc (and spike if you're interested in 
> playing around with that).  I tried using riscv64-unknown-gnu-linux-gcc, but 
> I encountered a problem where gem5 would return from a function and then read 
> 0x as an instruction even though the instruction at the corresponding 
> PC in the assembly is valid.
> 
> This doesn't appear to be your problem, though.  Your instruction appears 
> to be a multiply instruction, which isn't part of RV64I.  I'm not sure why 
> the compiler would do that when you specified -march=RV64I unless that's just 
> a suggestion and doesn't bind it to anything.  However, I do recall that 
> riscv64-unknown-elf-gcc should not use a multiply when invoking printf with 
> only a single argument that's a string literal.
> 
> I think your options are to either apply patch 2, which adds integer 
> multiply instructions, or try using riscv64-uknown-elf-gcc instead of 
> riscv64-unknown-gnu-linux-gcc.  I would recommend the former, since trying 
> the latter might cause a different problem that I mentioned earlier.  If all 
> you want to do is run something, there should also be a precompiled hello 
> binary in tests/test-progs/hello/bin/riscv/linux/.
> 
> Alec Roelke wrote:
> I forgot to mention, I've just been using straight configs/example/se.py 
> to run my code.  I don't think that should make a difference, though.
> 
> Jason Lowe-Power wrote:
> Ok. I'll play around with it soon.
> 
> The binary isn't in the diff, unfortunately. That's why I was compiling 
> it on my 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.
> 
> Jason Lowe-Power wrote:
> I see, I bet it was that I fixed some of the include orderings and got 
> that error.
> 
> I have another question, though...
> 
> I'm trying to test this out myself. I downloaded the compiler from 
> https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
> `riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
> -march=RV64I`.
> 
> When trying to run the binary I'm getting the error
> ```
> panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
>  @ tick 318000
> ```
> 
> What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py 
> with changes to use the atomic CPU instead of the timing.
> 
> Thanks for all your work!
> 
> Alec Roelke wrote:
> I have been using riscv64-unknown-elf-gcc rather than 
> riscv64-unknown-gnu-linux-gcc.  I don't know if riscv-gnu-toolchain will 
> build riscv64-unknown-elf-gcc, but you can get riscv-tools and build that, 
> and then you get riscv64-unknown-elf-gcc (and spike if you're interested in 
> playing around with that).  I tried using riscv64-unknown-gnu-linux-gcc, but 
> I encountered a problem where gem5 would return from a function and then read 
> 0x as an instruction even though the instruction at the corresponding 
> PC in the assembly is valid.
> 
> This doesn't appear to be your problem, though.  Your instruction appears 
> to be a multiply instruction, which isn't part of RV64I.  I'm not sure why 
> the compiler would do that when you specified -march=RV64I unless that's just 
> a suggestion and doesn't bind it to anything.  However, I do recall that 
> riscv64-unknown-elf-gcc should not use a multiply when invoking printf with 
> only a single argument that's a string literal.
> 
> I think your options are to either apply patch 2, which adds integer 
> multiply instructions, or try using riscv64-uknown-elf-gcc instead of 
> riscv64-unknown-gnu-linux-gcc.  I would recommend the former, since trying 
> the latter might cause a different problem that I mentioned earlier.  If all 
> you want to do is run something, there should also be a precompiled hello 
> binary in tests/test-progs/hello/bin/riscv/linux/.
> 
> Alec Roelke wrote:
> I forgot to mention, I've just been using straight configs/example/se.py 
> to run my code.  I don't think that should make a difference, though.
> 
> Jason Lowe-Power wrote:
> Ok. I'll play around with it soon.
> 
> The binary isn't in the diff, unfortunately. That's why I was compiling 
> it on my 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Jason Lowe-Power


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.
> 
> Jason Lowe-Power wrote:
> I see, I bet it was that I fixed some of the include orderings and got 
> that error.
> 
> I have another question, though...
> 
> I'm trying to test this out myself. I downloaded the compiler from 
> https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
> `riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
> -march=RV64I`.
> 
> When trying to run the binary I'm getting the error
> ```
> panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
>  @ tick 318000
> ```
> 
> What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py 
> with changes to use the atomic CPU instead of the timing.
> 
> Thanks for all your work!
> 
> Alec Roelke wrote:
> I have been using riscv64-unknown-elf-gcc rather than 
> riscv64-unknown-gnu-linux-gcc.  I don't know if riscv-gnu-toolchain will 
> build riscv64-unknown-elf-gcc, but you can get riscv-tools and build that, 
> and then you get riscv64-unknown-elf-gcc (and spike if you're interested in 
> playing around with that).  I tried using riscv64-unknown-gnu-linux-gcc, but 
> I encountered a problem where gem5 would return from a function and then read 
> 0x as an instruction even though the instruction at the corresponding 
> PC in the assembly is valid.
> 
> This doesn't appear to be your problem, though.  Your instruction appears 
> to be a multiply instruction, which isn't part of RV64I.  I'm not sure why 
> the compiler would do that when you specified -march=RV64I unless that's just 
> a suggestion and doesn't bind it to anything.  However, I do recall that 
> riscv64-unknown-elf-gcc should not use a multiply when invoking printf with 
> only a single argument that's a string literal.
> 
> I think your options are to either apply patch 2, which adds integer 
> multiply instructions, or try using riscv64-uknown-elf-gcc instead of 
> riscv64-unknown-gnu-linux-gcc.  I would recommend the former, since trying 
> the latter might cause a different problem that I mentioned earlier.  If all 
> you want to do is run something, there should also be a precompiled hello 
> binary in tests/test-progs/hello/bin/riscv/linux/.
> 
> Alec Roelke wrote:
> I forgot to mention, I've just been using straight configs/example/se.py 
> to run my code.  I don't think that should make a difference, though.

Ok. I'll play around with it soon.

The binary isn't in the diff, unfortunately. That's why I was compiling it on 
my own. If I still have issues I may ask you to 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.
> 
> Jason Lowe-Power wrote:
> I see, I bet it was that I fixed some of the include orderings and got 
> that error.
> 
> I have another question, though...
> 
> I'm trying to test this out myself. I downloaded the compiler from 
> https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
> `riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
> -march=RV64I`.
> 
> When trying to run the binary I'm getting the error
> ```
> panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
>  @ tick 318000
> ```
> 
> What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py 
> with changes to use the atomic CPU instead of the timing.
> 
> Thanks for all your work!
> 
> Alec Roelke wrote:
> I have been using riscv64-unknown-elf-gcc rather than 
> riscv64-unknown-gnu-linux-gcc.  I don't know if riscv-gnu-toolchain will 
> build riscv64-unknown-elf-gcc, but you can get riscv-tools and build that, 
> and then you get riscv64-unknown-elf-gcc (and spike if you're interested in 
> playing around with that).  I tried using riscv64-unknown-gnu-linux-gcc, but 
> I encountered a problem where gem5 would return from a function and then read 
> 0x as an instruction even though the instruction at the corresponding 
> PC in the assembly is valid.
> 
> This doesn't appear to be your problem, though.  Your instruction appears 
> to be a multiply instruction, which isn't part of RV64I.  I'm not sure why 
> the compiler would do that when you specified -march=RV64I unless that's just 
> a suggestion and doesn't bind it to anything.  However, I do recall that 
> riscv64-unknown-elf-gcc should not use a multiply when invoking printf with 
> only a single argument that's a string literal.
> 
> I think your options are to either apply patch 2, which adds integer 
> multiply instructions, or try using riscv64-uknown-elf-gcc instead of 
> riscv64-unknown-gnu-linux-gcc.  I would recommend the former, since trying 
> the latter might cause a different problem that I mentioned earlier.  If all 
> you want to do is run something, there should also be a precompiled hello 
> binary in tests/test-progs/hello/bin/riscv/linux/.

I forgot to mention, I've just been using straight configs/example/se.py to run 
my code.  I don't think that should make a difference, though.


- Alec


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8945

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.
> 
> Jason Lowe-Power wrote:
> I see, I bet it was that I fixed some of the include orderings and got 
> that error.
> 
> I have another question, though...
> 
> I'm trying to test this out myself. I downloaded the compiler from 
> https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
> `riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
> -march=RV64I`.
> 
> When trying to run the binary I'm getting the error
> ```
> panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
>  @ tick 318000
> ```
> 
> What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py 
> with changes to use the atomic CPU instead of the timing.
> 
> Thanks for all your work!

I have been using riscv64-unknown-elf-gcc rather than 
riscv64-unknown-gnu-linux-gcc.  I don't know if riscv-gnu-toolchain will build 
riscv64-unknown-elf-gcc, but you can get riscv-tools and build that, and then 
you get riscv64-unknown-elf-gcc (and spike if you're interested in playing 
around with that).  I tried using riscv64-unknown-gnu-linux-gcc, but I 
encountered a problem where gem5 would return from a function and then read 
0x as an instruction even though the instruction at the corresponding 
PC in the assembly is valid.

This doesn't appear to be your problem, though.  Your instruction appears to be 
a multiply instruction, which isn't part of RV64I.  I'm not sure why the 
compiler would do that when you specified -march=RV64I unless that's just a 
suggestion and doesn't bind it to anything.  However, I do recall that 
riscv64-unknown-elf-gcc should not use a multiply when invoking printf with 
only a single argument that's a string literal.

I think your options are to either apply patch 2, which adds integer multiply 
instructions, or try using riscv64-uknown-elf-gcc instead of 
riscv64-unknown-gnu-linux-gcc.  I would recommend the former, since trying the 
latter might cause a different problem that I mentioned earlier.  If all you 
want to do is run something, there should also be a precompiled hello binary in 
tests/test-progs/hello/bin/riscv/linux/.


- Alec


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8945
---


On Oct. 21, 2016, 6:12 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Jason Lowe-Power


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).
> 
> Alec Roelke wrote:
> Okay, I'll fix the rest of them, then (and in other patches too).
> 
> I actually figured it out.  In my original code, there was a weird bug in 
> isa/includes.isa where sim/system.hh had to be included out of order in, I 
> believe, the decoder or the errors you mentioned would pop up.  I added an 
> include for it into registers.hh and it fixed it.

I see, I bet it was that I fixed some of the include orderings and got that 
error.

I have another question, though...

I'm trying to test this out myself. I downloaded the compiler from 
https://github.com/riscv/riscv-gnu-toolchain and then build hello with 
`riscv64-unknown-linux-gnu-gcc ../../../src/hello.c -o hello -static 
-march=RV64I`.

When trying to run the binary I'm getting the error
```
panic: Unknown instruction 0x03755433 at pc 0x0002e1b8
 @ tick 318000
```

What am I doing wrong? I'm using configs/learning_gem5/part1/simple.py with 
changes to use the atomic CPU instead of the timing.

Thanks for all your work!


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8945
---


On Oct. 21, 2016, 6:12 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 21, 2016, 6:12 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:f84b3613acf4
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world\!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed 

Re: [gem5-dev] Review Request 3668: riscv: [Patch 6/5] Improve Linux emulation for RISC-V

2016-10-21 Thread Alec Roelke

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3668/
---

(Updated Oct. 21, 2016, 6:33 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11693:ac593e3451c7
---
riscv: [Patch 6/5] Improve Linux emulation for RISC-V

This is an add-on patch for the original series that implemented RISC-V
that improves the implementation of Linux emulation for SE mode. Basically
it cleans up linux/linux.hh by removing constants that haven't been
defined for the RISC-V Linux proxy kernel and rearranging the stat
struct so it aligns with RISC-V's implementation of it. It also adds
placeholders for system calls that have been given numbers in RISC-V
but haven't been given implementations yet. These system calls are
as follows:
- readlinkat
- sigprocmask
- ioctl
- clock_gettime
- getrusage
- getrlimit
- setrlimit

The first five patches implemented RISC-V with the base ISA and multiply,
floating point, and atomic extensions and added support for detailed
CPU models with memory timing.

[Fixed incompatibility with changes made from patch 1.]
Signed-off by: Alec Roelke


Diffs (updated)
-

  src/arch/riscv/linux/linux.hh PRE-CREATION 
  src/arch/riscv/linux/process.cc PRE-CREATION 

Diff: http://reviews.gem5.org/r/3668/diff/


Testing
---


Thanks,

Alec Roelke

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


Re: [gem5-dev] Review Request 3630: riscv: [Patch 5/5] Added missing support for timing CPU models

2016-10-21 Thread Alec Roelke

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3630/
---

(Updated Oct. 21, 2016, 6:32 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11692:600edba2ff50
---
riscv: [Patch 5/5] Added missing support for timing CPU models

Last of five patches adding RISC-V to GEM5. This patch adds support for
timing, minor, and detailed CPU models that was missing in the last four,
which basically consists of handling timing-mode memory accesses and
telling the minor and detailed models what a no-op instruction should
be (addi zero, zero, 0).

Patches 1-4 introduced RISC-V and implemented the base instruction set,
RV64I, and added the multiply, floating point, and atomic memory
extensions, RV64MAFD.

[Fixed compatibility with edit from patch 1.]
[Fixed compatibility with hg copy edit from patch 1.]
[Fixed some style errors in locked_mem.hh.]
Signed-off by: Alec Roelke


Diffs (updated)
-

  build_opts/RISCV PRE-CREATION 
  src/arch/riscv/isa_traits.hh PRE-CREATION 
  src/arch/riscv/locked_mem.hh PRE-CREATION 

Diff: http://reviews.gem5.org/r/3630/diff/


Testing
---


Thanks,

Alec Roelke

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


Re: [gem5-dev] Review Request 3628: riscv: [Patch 3/5] Added RISCV floating point extensions RV64FD

2016-10-21 Thread Alec Roelke

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3628/
---

(Updated Oct. 21, 2016, 6:27 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11690:edbd7b2b60b4
---
riscv: [Patch 3/5] Added RISCV floating point extensions RV64FD

Third of five patches adding RISC-V to GEM5. This patch adds the RV64FD
extensions, which include single- and double-precision floating point
instructions.

Patch 1 introduced RISC-V and implemented the base instruction set, RV64I
and patch 2 implemented the integer multiply extension, RV64M.

Patch 4 will implement the atomic memory instructions, RV64A, and patch
5 will add support for timing, minor, and detailed CPU models that is
missing from the first four patches.

[Fixed exception handling in floating-point instructions to conform better
to IEEE-754 2008 standard and behavior of the Chisel-generated RISC-V
simulator.]
[Fixed style errors in decoder.isa.]
Signed-off by: Alec Roelke


Diffs (updated)
-

  src/arch/riscv/faults.hh PRE-CREATION 
  src/arch/riscv/faults.cc PRE-CREATION 
  src/arch/riscv/isa/bitfields.isa PRE-CREATION 
  src/arch/riscv/isa/decoder.isa PRE-CREATION 
  src/arch/riscv/isa/formats/formats.isa PRE-CREATION 
  src/arch/riscv/isa/formats/fp.isa PRE-CREATION 
  src/arch/riscv/isa/includes.isa PRE-CREATION 
  src/arch/riscv/isa/operands.isa PRE-CREATION 
  src/arch/riscv/registers.hh PRE-CREATION 
  src/arch/riscv/utility.hh PRE-CREATION 

Diff: http://reviews.gem5.org/r/3628/diff/


Testing
---


Thanks,

Alec Roelke

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


Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke


> On Oct. 20, 2016, 7:10 p.m., Steve Reinhardt wrote:
> > src/arch/riscv/microcode_rom.hh, line 38
> > 
> >
> > Do you really need a microcode ROM? Seems like this whole file should 
> > not be necessary.

I don't think it should be required, but microcode_rom.hh is required by 
mem/abstract_mem.cc and the type MicrocodeRom is needed by several files in 
cpu, so it's just copied from another ISA.


- Alec


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8952
---


On Oct. 21, 2016, 6:12 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 21, 2016, 6:12 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:f84b3613acf4
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world\!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed formatting of several files, removed some variables and
> instructions that were missed when moving them to other patches, fixed
> RISC-V Foundation copyright attribution, and fixed history of files
> copied from other architectures using hg copy.]
> [Fixed indentation of switch cases in isa.cc.]
> [Reorganized syscall descriptions in linux/process.cc to remove large
> number of repeated unimplemented system calls and added implmementations
> to functions that have received them since it process.cc was first
> created.]
> [Fixed spacing for some copyright attributions.]
> [Replaced the rest of the file copies using hg copy.]
> [Fixed style check errors and corrected unaligned memory accesses.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   src/arch/riscv/isa/bitfields.isa PRE-CREATION 
>   src/arch/riscv/isa/decoder.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/basic.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/formats.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/mem.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/type.isa PRE-CREATION 
>   src/arch/riscv/isa/formats/unknown.isa PRE-CREATION 
>   src/arch/riscv/isa/includes.isa PRE-CREATION 
>   src/arch/riscv/isa/main.isa PRE-CREATION 
>   src/arch/riscv/isa/operands.isa PRE-CREATION 
>   src/arch/riscv/isa_traits.hh PRE-CREATION 
>   src/arch/riscv/kernel_stats.hh PRE-CREATION 
>   src/arch/riscv/linux/linux.hh PRE-CREATION 
>   src/arch/riscv/linux/linux.cc PRE-CREATION 
>   src/arch/riscv/linux/process.hh PRE-CREATION 
>   src/arch/riscv/linux/process.cc PRE-CREATION 
>   src/arch/riscv/locked_mem.hh PRE-CREATION 
>   src/arch/riscv/microcode_rom.hh PRE-CREATION 
>   src/arch/riscv/mmapped_ipr.hh PRE-CREATION 
>   src/arch/riscv/pagetable.hh PRE-CREATION 
>   src/arch/riscv/pagetable.cc PRE-CREATION 
>   src/arch/riscv/pra_constants.hh PRE-CREATION 
>   src/arch/riscv/system.hh PRE-CREATION 
>   src/arch/riscv/stacktrace.hh PRE-CREATION 
>   src/arch/riscv/process.cc PRE-CREATION 
>   src/arch/riscv/pseudo_inst.hh PRE-CREATION 
>   src/sim/process.cc b3d5f0e9e258 
>   src/base/loader/object_file.hh b3d5f0e9e258 
>   src/arch/riscv/utility.hh PRE-CREATION 
>   src/arch/riscv/tlb.cc PRE-CREATION 
>   src/arch/riscv/system.cc PRE-CREATION 
>   src/arch/riscv/stacktrace.cc PRE-CREATION 
>   src/arch/riscv/remote_gdb.hh PRE-CREATION 
>   src/arch/riscv/remote_gdb.cc PRE-CREATION 
>   src/arch/riscv/registers.hh PRE-CREATION 
>   src/arch/riscv/process.hh PRE-CREATION 
>   src/cpu/BaseCPU.py b3d5f0e9e258 
>   src/arch/riscv/vtophys.hh PRE-CREATION 
>   

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/
---

(Updated Oct. 21, 2016, 6:12 p.m.)


Review request for Default.


Repository: gem5


Description (updated)
---

Changeset 11688:f84b3613acf4
---
arch: [Patch 1/5] Added RISC-V base instruction set RV64I

First of five patches adding RISC-V to GEM5. This patch introduces the
base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
The multiply, floating point, and atomic memory instructions will be added
in additional patches, as well as support for more detailed CPU models.
The loader is also modified to be able to parse RISC-V ELF files, and a
"Hello world\!" example for RISC-V is added to test-progs.

Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
the floating point (single- and double-precision) extensions, RV64FD;
patch 4 will implement the atomic memory instructions, RV64A, and patch 5
will add support for timing, minor, and detailed CPU models that is missing
from the first four patches (such as handling locked memory).

[Removed several unused parameters and imports from RiscvInterrupts.py,
RiscvISA.py, and RiscvSystem.py.]
[Fixed copyright information in RISC-V files copied from elsewhere that had
ARM licenses attached.]
[Reorganized instruction definitions in decoder.isa so that they are sorted
by opcode in preparation for the addition of ISA extensions M, A, F, D.]
[Fixed formatting of several files, removed some variables and
instructions that were missed when moving them to other patches, fixed
RISC-V Foundation copyright attribution, and fixed history of files
copied from other architectures using hg copy.]
[Fixed indentation of switch cases in isa.cc.]
[Reorganized syscall descriptions in linux/process.cc to remove large
number of repeated unimplemented system calls and added implmementations
to functions that have received them since it process.cc was first
created.]
[Fixed spacing for some copyright attributions.]
[Replaced the rest of the file copies using hg copy.]
[Fixed style check errors and corrected unaligned memory accesses.]
Signed-off by: Alec Roelke


Diffs (updated)
-

  src/arch/riscv/isa/bitfields.isa PRE-CREATION 
  src/arch/riscv/isa/decoder.isa PRE-CREATION 
  src/arch/riscv/isa/formats/basic.isa PRE-CREATION 
  src/arch/riscv/isa/formats/formats.isa PRE-CREATION 
  src/arch/riscv/isa/formats/mem.isa PRE-CREATION 
  src/arch/riscv/isa/formats/type.isa PRE-CREATION 
  src/arch/riscv/isa/formats/unknown.isa PRE-CREATION 
  src/arch/riscv/isa/includes.isa PRE-CREATION 
  src/arch/riscv/isa/main.isa PRE-CREATION 
  src/arch/riscv/isa/operands.isa PRE-CREATION 
  src/arch/riscv/isa_traits.hh PRE-CREATION 
  src/arch/riscv/kernel_stats.hh PRE-CREATION 
  src/arch/riscv/linux/linux.hh PRE-CREATION 
  src/arch/riscv/linux/linux.cc PRE-CREATION 
  src/arch/riscv/linux/process.hh PRE-CREATION 
  src/arch/riscv/linux/process.cc PRE-CREATION 
  src/arch/riscv/locked_mem.hh PRE-CREATION 
  src/arch/riscv/microcode_rom.hh PRE-CREATION 
  src/arch/riscv/mmapped_ipr.hh PRE-CREATION 
  src/arch/riscv/pagetable.hh PRE-CREATION 
  src/arch/riscv/pagetable.cc PRE-CREATION 
  src/arch/riscv/pra_constants.hh PRE-CREATION 
  src/arch/riscv/system.hh PRE-CREATION 
  src/arch/riscv/stacktrace.hh PRE-CREATION 
  src/arch/riscv/process.cc PRE-CREATION 
  src/arch/riscv/pseudo_inst.hh PRE-CREATION 
  src/sim/process.cc b3d5f0e9e258 
  src/base/loader/object_file.hh b3d5f0e9e258 
  src/arch/riscv/utility.hh PRE-CREATION 
  src/arch/riscv/tlb.cc PRE-CREATION 
  src/arch/riscv/system.cc PRE-CREATION 
  src/arch/riscv/stacktrace.cc PRE-CREATION 
  src/arch/riscv/remote_gdb.hh PRE-CREATION 
  src/arch/riscv/remote_gdb.cc PRE-CREATION 
  src/arch/riscv/registers.hh PRE-CREATION 
  src/arch/riscv/process.hh PRE-CREATION 
  src/cpu/BaseCPU.py b3d5f0e9e258 
  src/arch/riscv/vtophys.hh PRE-CREATION 
  src/base/loader/elf_object.cc b3d5f0e9e258 
  src/arch/riscv/types.hh PRE-CREATION 
  src/arch/riscv/tlb.hh PRE-CREATION 
  src/arch/riscv/isa.hh PRE-CREATION 
  src/arch/riscv/isa.cc PRE-CREATION 
  src/arch/riscv/isa/base.isa PRE-CREATION 
  src/arch/riscv/decoder.hh PRE-CREATION 
  src/arch/riscv/decoder.cc PRE-CREATION 
  src/arch/riscv/faults.hh PRE-CREATION 
  src/arch/riscv/faults.cc PRE-CREATION 
  src/arch/riscv/idle_event.hh PRE-CREATION 
  src/arch/riscv/idle_event.cc PRE-CREATION 
  src/arch/riscv/interrupts.hh PRE-CREATION 
  src/arch/riscv/interrupts.cc PRE-CREATION 
  src/arch/riscv/RiscvSystem.py PRE-CREATION 
  src/arch/riscv/RiscvTLB.py PRE-CREATION 
  src/arch/riscv/SConscript PRE-CREATION 
  src/arch/riscv/SConsopts PRE-CREATION 
  build_opts/RISCV PRE-CREATION 
  ext/libelf/elf_common.h b3d5f0e9e258 
  src/arch/riscv/RiscvISA.py PRE-CREATION 
  src/arch/riscv/RiscvInterrupts.py PRE-CREATION 

Diff: 

Re: [gem5-dev] macro (and identifier) problems in our source code

2016-10-21 Thread Gutierrez, Anthony
Yes, I agree the _name designations are meant for clashes between private 
members and their accessors. I would also prefer that members still use camel 
case, and I'm not a fan of m_ to designate members. We could think about 
prepending get/set in front of accessors, but I doubt that will be popular 
either.

As far as include guards go, your suggestion is fine, although I think any 
conflicts are currently due to incorrectly formatted include guards. I believe 
the correct format is supposed to be like:

__PATH_IN_GEM5_SRC_TREE_FILE_NAME_HH__

But a lot of people seem to leave off the path name.

As far as the macros go, I am not crazy about adding 5 characters either  
(GEM5_). That said I think we should probably not be using macros for many 
things we currently use them for; i.e., we should be using inlines, constexpr, 
and consts. So if we could restrict our usage of macros to the few cases they 
are needed, then I think requiring GEM5_ for macros would be ok.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Potter, Brandon
Sent: Monday, October 10, 2016 3:02 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] macro (and identifier) problems in our source code

Hi Andreas,

I thought that the _name designations were meant for private members with 
accessors; that's what the style guide says: "Class members that have accessor 
methods should have a leading underscore to indicate that the user should be 
using an accessor. The accessor functions themselves should have the same name 
as the variable without the leading underscore." It's not always an issue with 
the members being named with an underscore, but I have seen cases with acronyms 
as the first few characters with full capitalization... so an error according 
to the C++ standard.

The macros in "src/base/misc.hh" that are used extensively are named panic, 
warn, and fatal. These are examples which are particularly likely to cause 
conflicts (as I found out this past weekend). The problem manifested as an 
error after a macro called another macro caused by a conflict on a function 
name. So, preprocessor sees the "warn" define from "misc.hh" and then sees 
"warn" from . It has already seen the macro so it decides to start 
replacing the declaration in the  header file.  Since the "warn" macro 
from "misc.hh" called another macro it was tough to track the problem down; the 
compiler pointed me to the nested macro and I stared at that code and the 
surrounding code for a while before realizing the problem with . Also, 
the header that included "misc.hh" was nested in the header file a few includes 
away.  Frankly, it was a waste of time that other developers probably would 
like to avoid going forward. I'm suggesting added the extra characters so that 
no one else runs into the problem again (at least as long as we don't include 
header files from the OTHER gem5 project). I know that it will offset the code 
and likely cause some line issues that need to be resolved, but it seems like a 
better programming practice to adopt rather than maintain the status quo and 
continue to add code.  I do agree that it's unfortunate though to need the 
extra characters However, imagine how nice it would be now if it had been 
adopted earlier in development.  You'd be able to look at a macro and know that 
it's a macro without needing to resort to header files to verify; also, you'd 
know that it was unique and need not worry about collisions.

Regards,
Brandon

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Monday, October 10, 2016 4:14 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] macro (and identifier) problems in our source code

Hi Brandon,

No objection on the header include guards.

When it comes to private members, I would suggest to just stick with nameOfVar. 
We have only used _name when there is a constructor parameter name, and it is 
actually not necessary. It is fine to have the private member be just name, and 
let the constructor parameter name initialise it with name(name).

What macros are causing problems? Adding 5 characters to each and everyone 
seems rather unfortunate.

Andreas

On 10/10/2016, 18:52, "gem5-dev on behalf of Potter, Brandon"
 wrote:

>Hello all,
>
>I just posted a patch, http://reviews.gem5.org/r/3650/, which deals 
>with a name collision between a macro that's defined in our source and 
>a function declaration included from a standard header. Seems like a 
>rare collision that I stumbled into, but we should do a better job of 
>naming our macros given that collisions are a possibility. With macros, 
>we can't use namespaces to prevent this from happening, but we could 
>make a rule where we append something like "_GEM5" onto all of the 
>macros. (It is a much larger problem than function names which is what 

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Alec Roelke


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.
> 
> Jason Lowe-Power wrote:
> Thanks for fixing the style errors. Although there are still some places 
> that don't follow the style guide in the code, we try to fix all of these as 
> we find them. Definitely any new code should follow all of the style 
> guidelines.
> 
> I'm not sure why I was having errors yesterday. They've magically 
> resolved themselves overnight. Hopefully you didn't spend too much time 
> looking into it :).

Okay, I'll fix the rest of them, then (and in other patches too).

I actually figured it out.  In my original code, there was a weird bug in 
isa/includes.isa where sim/system.hh had to be included out of order in, I 
believe, the decoder or the errors you mentioned would pop up.  I added an 
include for it into registers.hh and it fixed it.


- Alec


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8945
---


On Oct. 13, 2016, 4:48 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 13, 2016, 4:48 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11655:fce68047f694
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed formatting of several files, removed some variables and
> instructions that were missed when moving them to other patches, fixed
> RISC-V Foundation copyright attribution, and fixed history of files
> copied from other architectures using hg copy.]
> [Fixed indentation of switch cases in isa.cc.]
> [Reorganized syscall descriptions in linux/process.cc to remove large
> number of repeated unimplemented system calls and added implmementations
> to functions that have received them since it process.cc was first
> created.]
> [Fixed spacing for some copyright attributions.]
> [Replaced the rest of the file copies using hg copy.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   

Re: [gem5-dev] Review Request 3624: arch: [Patch 1/5] Added RISC-V base instruction set RV64I

2016-10-21 Thread Jason Lowe-Power


> On Oct. 20, 2016, 2:35 p.m., Jason Lowe-Power wrote:
> > Sorry for the slow reviewing. I have a few minor changes.
> > 
> > First, when I apply the patch, I get a number of errors from the style 
> > checker. Make sure you're using the most up-to-date version of gem5 when 
> > you rebase your patch.
> > 
> > Second, when I apply the patch and try to compile, I get a number of 
> > errors. Most are about the endianness functions:
> > `build/RISCV/config/the_isa.hh:25:16: error: 'gtoh' is not a member of 
> > 'RiscvISA'`
> > 
> > Third, I'm getting a number of "unused-variable" warnings (errors). If the 
> > variables are used for debugging (e.g., in asserts) you can use the macro 
> > M5_VAR_USED after the variable name and before the assignment.
> > 
> > I'm not sure if the problem is that you've based this on an older version 
> > of gem5, or maybe we're just using different compilers (I'm use gcc-4.8).
> 
> Alec Roelke wrote:
> I ignored a few of the style warnings because I saw some other places in 
> gem5's code where the character limit was ignored.  I'll go back through and 
> try to fix them all though.  I think for remote_gdb there are some (a lot of) 
> warnings about "invalid control characters" that I wasn't sure how to fix.
> 
> I built this using a system running Ubuntu 16.04, which has gcc 5.3 and 
> doesn't have any errors or warnings like you're describing.  I tried 
> compiling it on a virtual machine running Ubuntu 14.04 and gcc 4.8.4, it also 
> works.  I tested with gem5.debug and gem5.fast.

Thanks for fixing the style errors. Although there are still some places that 
don't follow the style guide in the code, we try to fix all of these as we find 
them. Definitely any new code should follow all of the style guidelines.

I'm not sure why I was having errors yesterday. They've magically resolved 
themselves overnight. Hopefully you didn't spend too much time looking into it 
:).


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3624/#review8945
---


On Oct. 13, 2016, 4:48 p.m., Alec Roelke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3624/
> ---
> 
> (Updated Oct. 13, 2016, 4:48 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11655:fce68047f694
> ---
> arch: [Patch 1/5] Added RISC-V base instruction set RV64I
> 
> First of five patches adding RISC-V to GEM5. This patch introduces the
> base 64-bit ISA (RV64I) in src/arch/riscv for use with syscall emulation.
> The multiply, floating point, and atomic memory instructions will be added
> in additional patches, as well as support for more detailed CPU models.
> The loader is also modified to be able to parse RISC-V ELF files, and a
> "Hello world!" example for RISC-V is added to test-progs.
> 
> Patch 2 will implement the multiply extension, RV64M; patch 3 will implement
> the floating point (single- and double-precision) extensions, RV64FD;
> patch 4 will implement the atomic memory instructions, RV64A, and patch 5
> will add support for timing, minor, and detailed CPU models that is missing
> from the first four patches (such as handling locked memory).
> 
> [Removed several unused parameters and imports from RiscvInterrupts.py,
> RiscvISA.py, and RiscvSystem.py.]
> [Fixed copyright information in RISC-V files copied from elsewhere that had
> ARM licenses attached.]
> [Reorganized instruction definitions in decoder.isa so that they are sorted
> by opcode in preparation for the addition of ISA extensions M, A, F, D.]
> [Fixed formatting of several files, removed some variables and
> instructions that were missed when moving them to other patches, fixed
> RISC-V Foundation copyright attribution, and fixed history of files
> copied from other architectures using hg copy.]
> [Fixed indentation of switch cases in isa.cc.]
> [Reorganized syscall descriptions in linux/process.cc to remove large
> number of repeated unimplemented system calls and added implmementations
> to functions that have received them since it process.cc was first
> created.]
> [Fixed spacing for some copyright attributions.]
> [Replaced the rest of the file copies using hg copy.]
> Signed-off by: Alec Roelke
> 
> 
> Diffs
> -
> 
>   build_opts/RISCV PRE-CREATION 
>   ext/libelf/elf_common.h 49cbf4bb0d36 
>   src/arch/riscv/RiscvISA.py PRE-CREATION 
>   src/arch/riscv/RiscvInterrupts.py PRE-CREATION 
>   src/arch/riscv/RiscvSystem.py PRE-CREATION 
>   src/arch/riscv/RiscvTLB.py PRE-CREATION 
>   src/arch/riscv/SConscript PRE-CREATION 
>   src/arch/riscv/SConsopts PRE-CREATION 
>   src/arch/riscv/decoder.hh PRE-CREATION 
>   

Re: [gem5-dev] Review Request 3502: mem: Split the hit_latency into tag_latency and data_latency

2016-10-21 Thread Jason Lowe-Power


> On Oct. 21, 2016, 1:29 p.m., Pierre-Yves Péneau wrote:
> > Hi,
> > 
> > Someone can commit this patch ? I don't have right access on the 
> > repository, either Sophiane.
> > Thank you.

Sorry we've been so slow on this patch. A couple of questions before I commit.

1. Are all of Andreas H.'s comments resolved? I'd like to see a "Ship It" from 
him.
2. You need to make sure the regressions are passing. I understand that our 
regression testing is poor, but I know that the learning_gem5 regression is 
failing because of this patch. The file configs/learning_gem5/part1/caches.py 
needs to be updated. There are likely other files that need to be updated as 
well (configs/examples/arm/devices.py comes to mind, there may be others).


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/#review8960
---


On July 28, 2016, 10:31 a.m., Sophiane SENNI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3502/
> ---
> 
> (Updated July 28, 2016, 10:31 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11536:1a3a96d435ed
> ---
> mem: Split the hit_latency into tag_latency and data_latency
> 
> If the cache access mode is parallel, i.e. "sequential_access" parameter 
> is set to "False", tags and data are accessed in parallel. Therefore,
> the hit_latency is the maximum latency between tag_latency and
> data_latency. On the other hand, if the cache access mode is
> sequential, i.e. "sequential_access" parameter is set to "True", 
> tags and data are accessed sequentially. Therefore, the hit_latency
> is the sum of tag_latency plus data_latency.
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   configs/common/O3_ARM_v7a.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/Cache.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/Tags.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base_set_assoc.hh 
> 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/fa_lru.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
> 
> Diff: http://reviews.gem5.org/r/3502/diff/
> 
> 
> Testing
> ---
> 
> Tested using --Debug-flags=Cache
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

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


Re: [gem5-dev] Review Request 3502: mem: Split the hit_latency into tag_latency and data_latency

2016-10-21 Thread Pierre-Yves Péneau

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3502/#review8960
---


Hi,

Someone can commit this patch ? I don't have right access on the repository, 
either Sophiane.
Thank you.

- Pierre-Yves Péneau


On July 28, 2016, 12:31 p.m., Sophiane SENNI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3502/
> ---
> 
> (Updated July 28, 2016, 12:31 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11536:1a3a96d435ed
> ---
> mem: Split the hit_latency into tag_latency and data_latency
> 
> If the cache access mode is parallel, i.e. "sequential_access" parameter 
> is set to "False", tags and data are accessed in parallel. Therefore,
> the hit_latency is the maximum latency between tag_latency and
> data_latency. On the other hand, if the cache access mode is
> sequential, i.e. "sequential_access" parameter is set to "True", 
> tags and data are accessed sequentially. Therefore, the hit_latency
> is the sum of tag_latency plus data_latency.
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   configs/common/O3_ARM_v7a.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/Cache.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/Tags.py 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base.hh 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/base_set_assoc.hh 
> 4aac82f109517217e6bfb3812689280e7a8fa842 
>   src/mem/cache/tags/fa_lru.cc 4aac82f109517217e6bfb3812689280e7a8fa842 
> 
> Diff: http://reviews.gem5.org/r/3502/diff/
> 
> 
> Testing
> ---
> 
> Tested using --Debug-flags=Cache
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

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


Re: [gem5-dev] Review Request 3683: config: Break out base options for usage with NULL ISA

2016-10-21 Thread Andreas Hansson


> On Oct. 20, 2016, 2:11 p.m., Jason Lowe-Power wrote:
> > This is fine with me. However, I think this is just bandaging a broken 
> > system. IMO, we need to greatly simplify (maybe even totally remove) the 
> > command-line parameters in config/common.
> > 
> > What I've been telling people is this: gem5's interface is not the command 
> > line: it is Python scripts. You shouldn't think about "what options should 
> > I pass to gem5" when you are using it, you should instead say "what Python 
> > script should I write". 
> > 
> > My opinion is our scripts in configs/ should do two things:
> >  1. Break out commonalities between all Python configuration scripts. 
> > Things like DDR3 memory, basic cache coherence protocols, specific ARM CPU 
> > configurations, full system setup BS, etc.
> >  2. Give some basic examples of how to use Python configuration scripts, 
> > and give some starting points for new users to pick up gem5.
> > 
> > Sorry, this is off-topic for this patch, but it's something that's been 
> > bothering me for years now. This idea that many of our users have that you 
> > can just call gem5 with the "right" command line paramters to simulate what 
> > you need is harmful. It's harmful both to gem5 development as it makes 
> > these config scripts less maintainable (e.g., Ruby's scripts), and, in the 
> > worst case, produces bad architecture research since users can ignore 
> > important parameters.
> > 
> > /rant.
> > 
> > This isn't really a review of this patch, but I just wanted to say I don't 
> > think it's worth much of our time to try to bandage the current 
> > "Options.py" configuration style. Though, I'm not volunteering to fix this 
> > either. BTW, I think the ARM config scripts in configs/examples/arm are a 
> > step in the right direction, though I think they could be taken even 
> > further to make them cleaner and more maintainable.
> > 
> > Either way, thanks for making these changes, Andreas. We certainly can't 
> > have things that are generating errors for our users in the short term.

I completely agree that this is bandaid. I merely wanted to make sure things 
were somewhat less broken again and that people could use the existing scripts 
without things blowing up.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3683/#review8944
---


On Oct. 20, 2016, 11:07 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3683/
> ---
> 
> (Updated Oct. 20, 2016, 11:07 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11688:60b7de6442f3
> ---
> config: Break out base options for usage with NULL ISA
> 
> This patch breaks out the most basic configuration options into a set
> of base options, to allow them to be used also by scripts that do not
> involve any actual CPUs or devices. The patch also fixes a few modules
> so that they can be imported in a NULL build, and avoid dragging in
> FSConfig every time Options is imported.
> 
> 
> Diffs
> -
> 
>   configs/common/CpuConfig.py b3d5f0e9e258 
>   configs/common/FSConfig.py b3d5f0e9e258 
>   configs/common/Options.py b3d5f0e9e258 
>   configs/common/PlatformConfig.py b3d5f0e9e258 
>   configs/example/garnet_synth_traffic.py b3d5f0e9e258 
> 
> Diff: http://reviews.gem5.org/r/3683/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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


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

2016-10-21 Thread Cron Daemon
* 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-atomic: 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-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-mt: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic: 
passed.* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing: passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 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/00.hello/alpha/tru64/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/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/simple-atomic: 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/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: 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.
*