Re: [m5-dev] MIPS UTB and multiple inheritance.
Any luck? nathan binkert wrote: I'll try to figure this out, but I don't get it yet. I'll get an older compiler going... Nate On Fri, Mar 6, 2009 at 10:48 AM, Gabe Black gbl...@eecs.umich.edu wrote: I'm heading out the door, but I just tried building X86_SE on the head and it gave me the errors. I didn't think my changes caused them. I have similar problems with ALPHA_SE, and I haven't tried any other targets. gbl...@tater ~/m5/repos/m5.x86fs $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.1) gbl...@tater ~/m5/repos/m5.x86fs $ python -V Python 2.5.2 gbl...@tater ~/m5/repos/m5.x86fs $ swig -version SWIG Version 1.3.36 Compiled with x86_64-pc-linux-gnu-g++ [x86_64-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information gbl...@tater ~/m5/repos/m5.x86fs $ scons -v SCons by Steven Knight et al.: script: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok engine: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/pc_event.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/thread_context.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Steve Reinhardt wrote: On Fri, Mar 6, 2009 at 10:19 AM, Gabe Black gbl...@eecs.umich.edu wrote: nathan binkert wrote: You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an
Re: [m5-dev] MIPS UTB and multiple inheritance.
OK, so the solution should probably be move the ITB/DTB functions into one base TLB and then let a unified TLB derive off of that...correct? This would allow us the two standard ITB and DTB pointers we've been using...but also avoid multiple inheritance issues as well. On Fri, Mar 6, 2009 at 2:12 AM, nathan binkert n...@binkert.org wrote: Oh, I agree there. They may both point to the same thing (unified case), but they may not. Nate Having two pointers in the CPU for the DTB and ITB is still a necessity. If you're trying to model separate structures you're going to need two of them. Ali On Mar 6, 2009, at 1:13 AM, Gabe Black wrote: I think ITBs and DTBs are usually very similar differ in a few key ways like the nx (no execute) bit in x86 for example. In x86 the DTB and ITB classes are basically just wrappers around a common TLB with one translate function, and the DTB's and ITB's version just call that with an extra parameter or two. This should generally work across other ISAs as far as I know. If the translate functions really are radically different, there isn't much overhead in having them both in there and just picking one or the other based on that parameter. I think even the generic TLB that's for SE implementations that don't have an ISA specific TLB yet just looks things up in the page table no matter what your translating. As far as whether to get rid of the separation between the ITB and DTB I think it's a good idea. I can't think of any benefit to having the separation other than that it's already there, and while it hasn't caused any other problems it prevents Korey from having a UTB implementation. We'd likely want to give it parameters which let you independently configure it's ITB and DTB (or UTB) personalities, but that should be pretty easy. This should (knock on wood) be pretty easy to implement and I'd be happy to help. Gabe nathan binkert wrote: How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Philosophically, I agree... let's avoid virtual inheritance if at all possible. It's just not a good idea. Ok, so the question is, which of the other alternatives should we do? Gabe (mister TLB expert)? Korey (since this is mips code)? 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 ___ 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 -- -- 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] MIPS UTB and multiple inheritance.
Is the following correct? This is in the BaseCPU where it sets up the data and instruction TLBs it's going to use and installs defaults. I'm suspicious that this is actually installing a particular TLB to be the default in all of the CPUs, or in other words all CPUs share the same ITB and DTB. Am I crazy? dtb = Param.SparcDTB(SparcDTB(), Data TLB) itb = Param.SparcITB(SparcITB(), Instruction TLB) Gabe Gabe Black wrote: I'll keep both pointers then. I have all the non-ISA bits and X86 converted and I'm trying to test it, but I'm running into a compile error in the stats stuff. Nate? cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Gabe nathan binkert wrote: Oh, I agree there. They may both point to the same thing (unified case), but they may not. Nate Having two pointers in the CPU for the DTB and ITB is still a necessity. If you're trying to model separate structures you're going to need two of them. Ali On Mar 6, 2009, at 1:13 AM, Gabe Black wrote: I think ITBs and DTBs are usually very similar differ in a few key ways like the nx (no execute) bit in x86 for example. In x86 the DTB and ITB classes are basically just wrappers around a common TLB with one translate function, and the DTB's and ITB's version just call that with an extra parameter or two. This should generally work across other ISAs as far as I know. If the translate functions really are radically different, there isn't much overhead in having them both in there and just picking one or the other based on that parameter. I think even the generic TLB that's for SE implementations that don't have an ISA specific TLB yet just looks things up in the page table no matter what your translating. As far as whether to get rid of the separation between the ITB and DTB I think it's a good idea. I can't think of any benefit to having the separation other than that it's already there, and while it hasn't caused any other problems it prevents Korey from having a UTB implementation. We'd likely want to give it parameters which let you independently configure it's ITB and DTB (or UTB) personalities, but that should be pretty easy. This should (knock on wood) be pretty easy to implement and I'd be happy to help. Gabe nathan binkert wrote: How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Philosophically, I agree... let's avoid virtual inheritance if at all possible. It's just not a good idea. Ok, so the question is, which of the other alternatives should we do? Gabe (mister TLB expert)? Korey (since this is mips code)? 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 ___ 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
The ITB and DTB functions should be in -the- base TLB class I hope by the end of the weekend at the latest. The UTB can then be assigned to both ITB and DTB parameters and it should work. Gabe Korey Sewell wrote: OK, so the solution should probably be move the ITB/DTB functions into one base TLB and then let a unified TLB derive off of that...correct? This would allow us the two standard ITB and DTB pointers we've been using...but also avoid multiple inheritance issues as well. On Fri, Mar 6, 2009 at 2:12 AM, nathan binkert n...@binkert.org mailto:n...@binkert.org wrote: Oh, I agree there. They may both point to the same thing (unified case), but they may not. Nate Having two pointers in the CPU for the DTB and ITB is still a necessity. If you're trying to model separate structures you're going to need two of them. Ali On Mar 6, 2009, at 1:13 AM, Gabe Black wrote: I think ITBs and DTBs are usually very similar differ in a few key ways like the nx (no execute) bit in x86 for example. In x86 the DTB and ITB classes are basically just wrappers around a common TLB with one translate function, and the DTB's and ITB's version just call that with an extra parameter or two. This should generally work across other ISAs as far as I know. If the translate functions really are radically different, there isn't much overhead in having them both in there and just picking one or the other based on that parameter. I think even the generic TLB that's for SE implementations that don't have an ISA specific TLB yet just looks things up in the page table no matter what your translating. As far as whether to get rid of the separation between the ITB and DTB I think it's a good idea. I can't think of any benefit to having the separation other than that it's already there, and while it hasn't caused any other problems it prevents Korey from having a UTB implementation. We'd likely want to give it parameters which let you independently configure it's ITB and DTB (or UTB) personalities, but that should be pretty easy. This should (knock on wood) be pretty easy to implement and I'd be happy to help. Gabe nathan binkert wrote: How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Philosophically, I agree... let's avoid virtual inheritance if at all possible. It's just not a good idea. Ok, so the question is, which of the other alternatives should we do? Gabe (mister TLB expert)? Korey (since this is mips code)? Nate ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org mailto: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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
Gabe, aren't those per-CPU python parameters? In other words, each CPU instantiates it' own set of parameters in the config file through this python interface...right? On Fri, Mar 6, 2009 at 3:09 AM, Gabe Black gbl...@eecs.umich.edu wrote: Is the following correct? This is in the BaseCPU where it sets up the data and instruction TLBs it's going to use and installs defaults. I'm suspicious that this is actually installing a particular TLB to be the default in all of the CPUs, or in other words all CPUs share the same ITB and DTB. Am I crazy? dtb = Param.SparcDTB(SparcDTB(), Data TLB) itb = Param.SparcITB(SparcITB(), Instruction TLB) Gabe Gabe Black wrote: I'll keep both pointers then. I have all the non-ISA bits and X86 converted and I'm trying to test it, but I'm running into a compile error in the stats stuff. Nate? cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Gabe nathan binkert wrote: Oh, I agree there. They may both point to the same thing (unified case), but they may not. Nate Having two pointers in the CPU for the DTB and ITB is still a necessity. If you're trying to model separate structures you're going to need two of them. Ali On Mar 6, 2009, at 1:13 AM, Gabe Black wrote: I think ITBs and DTBs are usually very similar differ in a few key ways like the nx (no execute) bit in x86 for example. In x86 the DTB and ITB classes are basically just wrappers around a common TLB with one translate function, and the DTB's and ITB's version just call that with an extra parameter or two. This should generally work across other ISAs as far as I know. If the translate functions really are radically different, there isn't much overhead in having them both in there and just picking one or the other based on that parameter. I think even the generic TLB that's for SE implementations that don't have an ISA specific TLB yet just looks things up in the page table no matter what your translating. As far as whether to get rid of the separation between the ITB and DTB I think it's a good idea. I can't think of any benefit to having the separation other than that it's already there, and while it hasn't caused any other problems it prevents Korey from having a UTB implementation. We'd likely want to give it parameters which let you independently configure it's ITB and DTB (or UTB) personalities, but that should be pretty easy. This should (knock on wood) be pretty easy to implement and I'd be happy to help. Gabe nathan binkert wrote: How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Philosophically, I agree... let's avoid virtual inheritance if at all possible. It's just not a good idea. Ok, so the question is, which of the other alternatives should we do? Gabe (mister TLB expert)? Korey (since this is mips code)? 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 ___ 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 ___ 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] MIPS UTB and multiple inheritance.
I'll keep both pointers then. I have all the non-ISA bits and X86 converted and I'm trying to test it, but I'm running into a compile error in the stats stuff. Nate? cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an integer. Nothing magic here, just apply normal debugging techniques. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
On Fri, Mar 6, 2009 at 7:48 AM, nathan binkert n...@binkert.org wrote: Is the following correct? This is in the BaseCPU where it sets up the data and instruction TLBs it's going to use and installs defaults. I'm suspicious that this is actually installing a particular TLB to be the default in all of the CPUs, or in other words all CPUs share the same ITB and DTB. Am I crazy? dtb = Param.SparcDTB(SparcDTB(), Data TLB) itb = Param.SparcITB(SparcITB(), Instruction TLB) No, (at least this is my recollection, confirm please Steve). When you instantiate an object, it essentially does a deep copy of the tree that's there. Yea, that's right. If you want them to share the same object, you need to instantiate two separate objects and explicitly make them point to the same thing. Yes, if you want multiple CPUs to share a TLB you would need to instantiate all the CPUs first and then assign the same TLB to them afterward. Something like this: dtb = Param.SparcDTB(SparcTLB(), Data TLB) itb = Param.SparcITB(Self.dtb, Instruction TLB) should work fine for causing each CPU instance to have a single unified TLB. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
nathan binkert wrote: I'll keep both pointers then. I have all the non-ISA bits and X86 converted and I'm trying to test it, but I'm running into a compile error in the stats stuff. Nate? cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an integer. Nothing magic here, just apply normal debugging techniques. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I didn't add or substantially change any stats, though. I just renamed a few. I'll look into this more this evening. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
That's odd... if it doesn't work that way, I'd consider that a bug. On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black gbl...@eecs.umich.edu wrote: I tried something like this before, and I don't think it works because self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to instantiate those objects as regular members first I believe. This was the SouthBridge stuff. Gabe Yes, if you want multiple CPUs to share a TLB you would need to instantiate all the CPUs first and then assign the same TLB to them afterward. Something like this: dtb = Param.SparcDTB(SparcTLB(), Data TLB) itb = Param.SparcITB(Self.dtb, Instruction TLB) should work fine for causing each CPU instance to have a single unified TLB. Steve ___ 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
Re: [m5-dev] MIPS UTB and multiple inheritance.
On Fri, Mar 6, 2009 at 10:19 AM, Gabe Black gbl...@eecs.umich.edu wrote: nathan binkert wrote: You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an integer. Nothing magic here, just apply normal debugging techniques. I didn't add or substantially change any stats, though. I just renamed a few. I'll look into this more this evening. It's probably something that was not quite right before but the code let you get away with it, and now with Nate's changes it's a little more strict. Just guessing. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
I took a look at SouthBridge.py to see what you might have been trying... were you trying to access an attribute of the param, like: pic1 = Param.I8259(_pic1, Master PIC) [...] Self.pic1.output [...] I can see where that wouldn't work, as Self.pic1 is a proxy object that merely says look up pic1 later after everything's instantiated. Basically you can't do anything with it other than use it as a default for another param or (if it's numeric) you can do simple math with it (like '2 * Self.clock.latency'). Steve On Fri, Mar 6, 2009 at 10:27 AM, Steve Reinhardt ste...@gmail.com wrote: That's odd... if it doesn't work that way, I'd consider that a bug. On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black gbl...@eecs.umich.edu wrote: I tried something like this before, and I don't think it works because self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to instantiate those objects as regular members first I believe. This was the SouthBridge stuff. Gabe Yes, if you want multiple CPUs to share a TLB you would need to instantiate all the CPUs first and then assign the same TLB to them afterward. Something like this: dtb = Param.SparcDTB(SparcTLB(), Data TLB) itb = Param.SparcITB(Self.dtb, Instruction TLB) should work fine for causing each CPU instance to have a single unified TLB. Steve ___ 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
Re: [m5-dev] MIPS UTB and multiple inheritance.
I'm heading out the door, but I just tried building X86_SE on the head and it gave me the errors. I didn't think my changes caused them. I have similar problems with ALPHA_SE, and I haven't tried any other targets. gbl...@tater ~/m5/repos/m5.x86fs $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.1) gbl...@tater ~/m5/repos/m5.x86fs $ python -V Python 2.5.2 gbl...@tater ~/m5/repos/m5.x86fs $ swig -version SWIG Version 1.3.36 Compiled with x86_64-pc-linux-gnu-g++ [x86_64-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information gbl...@tater ~/m5/repos/m5.x86fs $ scons -v SCons by Steven Knight et al.: script: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok engine: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/pc_event.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/thread_context.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Steve Reinhardt wrote: On Fri, Mar 6, 2009 at 10:19 AM, Gabe Black gbl...@eecs.umich.edu wrote: nathan binkert wrote: You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an integer. Nothing magic here, just apply normal debugging techniques. I didn't add or substantially change any stats, though. I just renamed a few. I'll look into this more this evening. It's probably something that was not quite right before but the code let you get away with it, and now with Nate's
Re: [m5-dev] MIPS UTB and multiple inheritance.
That's odd... if it doesn't work that way, I'd consider that a bug. On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black gbl...@eecs.umich.edu wrote: I tried something like this before, and I don't think it works because self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to instantiate those objects as regular members first I believe. This was the SouthBridge stuff. I can't remember your specific situation, but I believe that it was special. If you can remind us (or just dig up the title on the e-mail thread), we can see if we can fix it. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
I'll try to figure this out, but I don't get it yet. I'll get an older compiler going... Nate On Fri, Mar 6, 2009 at 10:48 AM, Gabe Black gbl...@eecs.umich.edu wrote: I'm heading out the door, but I just tried building X86_SE on the head and it gave me the errors. I didn't think my changes caused them. I have similar problems with ALPHA_SE, and I haven't tried any other targets. gbl...@tater ~/m5/repos/m5.x86fs $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.1) gbl...@tater ~/m5/repos/m5.x86fs $ python -V Python 2.5.2 gbl...@tater ~/m5/repos/m5.x86fs $ swig -version SWIG Version 1.3.36 Compiled with x86_64-pc-linux-gnu-g++ [x86_64-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information gbl...@tater ~/m5/repos/m5.x86fs $ scons -v SCons by Steven Knight et al.: script: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok engine: v1.0.0.r3266, 2008/08/12 07:31:01, by knight on bangkok Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/pc_event.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' scons: *** [build/X86_SE/cpu/thread_context.o] Error 1 cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Steve Reinhardt wrote: On Fri, Mar 6, 2009 at 10:19 AM, Gabe Black gbl...@eecs.umich.edu wrote: nathan binkert wrote: You have a VectorDistribution stat somewhere, and you're calling its init() function with the first parameter as a float instead of an integer. Nothing magic here, just apply normal debugging
Re: [m5-dev] MIPS UTB and multiple inheritance.
Nate, I didn't directly implement that UTB part myself but I believe the mips utlb has some different features than a normal tlb which allows them to share one structure. I think that's part of their claim to fame so to speak... Unfortunately, I can't think of the exact mechanism right now, but I'll peek at the code again to be sure... On Fri, Mar 6, 2009 at 10:49 AM, nathan binkert n...@binkert.org wrote: Actually I take that back. That's how it would work if we used inheritance. The BaseTLB doesn't actually know to translate anything, so the UTB would provide it's own implementation directly. You'd still assign it to both ITB and DTB parameters. I still don't understand why there isn't truly just one TLB class. What would the UTB class be for? 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] MIPS UTB and multiple inheritance.
That may be true, but none of it is actually in the UTB that we have in our tree. All the UTB does is inherit from DTB and ITB and that's it. Although the UTB inheriting from the DTB and ITB seems pointless from the outset, the way it was implemented is that if you can combine the functionality of the ITB and DTB then you have a UTB. So instead of defining the functions separately in a UTB class, you can just inherit from the ITB and DTB classes and note that you would never want to have a separate ITB/DTB class for MIPS anyway. We've already discussed why deriving from the ITB and DTB was desirable as it allowed those base pointers to point the same UTB class. Is that the right implementation? Well, if you are trying to stick to the convention that there has to be an ITB and DTB pointer in each CPU then yes, because how else are you going to mimick the functionality of both in one class? But if we are willing to give BaseTLB pointers in the CPU's and just name those itb and dtb, then I would argue that that is a better solution as described earlier in this thread. Seems like Gabe is doing this anyway (right?), so this should be able to be resolved soon I would think. 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] MIPS UTB and multiple inheritance.
Seems like Gabe is doing this anyway (right?) Yes. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Philosophically, I agree... let's avoid virtual inheritance if at all possible. It's just not a good idea. Ok, so the question is, which of the other alternatives should we do? Gabe (mister TLB expert)? Korey (since this is mips code)? Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
On Thu, Mar 5, 2009 at 9:09 PM, nathan binkert n...@binkert.org wrote: How different are ITBs and DTBs anyway? It seems like for a UTB you'd want a single object that handles both ifetch and data translations using a common translate() method, not something that inherits from two different classes. E.g., why not just derive it from TLB? The two translation functions are different because every ISA does some different things for instructions vs data. Think about something like the executable bit. Right, but you could have a flag that says ifetch (or an ifetch/read/write enum in place of the read/write flag we have now) to control that behavior. Then the current ITB would panic on a read or write request, and the DTB would panic on an ifetch, but a UTB could handle all of the above. Or more realistically we could just punt on having separate ITB and DTB classes. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS UTB and multiple inheritance.
I believe the reason the UTB thing was done in that way was to try to match the current M5 infrastructure which require ITB and DTB pointers in every CPU model and have a few functions that hardcode (itb-___ or dtb-___). If you dont derive UTB from both ITB and DTB you'll have a problem there with compatibility...hence a big headache because you have to figure out how to create a single object representing the UTB but then get ITB/DTB base pointers to use the UTB version. I wouldn't say delete the UTB because you need that to boot Full System MIPS and doesn't some other ISA use Unified TLB as well? I'm not sure every drop of FS MIPS code made it into the tree, but you definitely need that UTB or it definitely wont work. So what's the solution? Well, it really depends on how willing we are to change how we traditionally use the ITB and DTB in M5 (as has been discussed previously). On Fri, Mar 6, 2009 at 12:17 AM, nathan binkert n...@binkert.org wrote: Right, but you could have a flag that says ifetch (or an ifetch/read/write enum in place of the read/write flag we have now) to control that behavior. Then the current ITB would panic on a read or write request, and the DTB would panic on an ifetch, but a UTB could handle all of the above. That's what I was suggesting with the extra parameter. So, it sounds like this is the right approach. Gabe, can you help me implement it? I'd think that it should be relatively easy, it probably just involves mostly busy work. Or more realistically we could just punt on having separate ITB and DTB classes. I personally think yes. I don't think it buys us very much. Maybe it shortens the rope we give the users when they build a configuration, but there's already way more than enough to allow a user to hang themselves. 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
