[m5-dev] Cron [EMAIL PROTECTED] /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. See /z/m5/regression/regress-2008-06-09-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure everything is unique.
Gabe
nathan binkert wrote:
I do think nested namespaces will work. When you do cxx_namespace,
you'd just say one::two::three
On Mon, Jun 2, 2008 at 6:59 PM, Ali Saidi [EMAIL PROTECTED] wrote:
I think Nate will have to say if Nested namespaces will work for SimObjects.
Perhaps a namespace like x86pc or something would be good for the tables.
I'm pretty sure most of that stuff is x86 only.
Ali
On Jun 2, 2008, at 9:53 PM, Gabe Black wrote:
This stuff is standardized for PCs but it might be useful for other
platforms as well. I'm not familiar enough with this stuff to really be able
to tell for sure, but if I had to guess I'd say it's not. I was thinking of
putting it in X86ISA and then into a nested BIOS namespace.
Gabe
Ali Saidi wrote:
Take a look at how the Alpha TLB is done for how to make
SimObjects/Python happy with namespaces. The Params builder function needs
to be in the global name space.
One question is should it go in the x86 name space or in something else?
Ali
On Jun 2, 2008, at 9:32 PM, Gabe Black wrote:
I'm just starting on making the BIOSey tables and configuration
information, like the e820 map which was forcing there to be 4 gigs of
memory, available through SimObjects. There are a bunch of hierarchical
tables for, for example, the DMI information, and I'm concerned that if I
add a bunch, maybe a few dozen, new names, I'll end up either colliding
with
things that exist or making collisions more likely later on. The obvious
C++
answer to that would be a namespace, but I'm not sure the best way to do
that in this circumstance. Regularly I think the python modules idea is
supposed to take care of this, but I'm not sure how that fits with our
stuff
and some of the fancy voodoo we've got making it all work. I'm going to
try
it that way and just see how it pans out, but if anyone has any input I'd
like to hear it.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
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
Params: Allow nested namespaces in cxx_namespace
diff -r 4944b77f70bd src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py Mon Jun 09 02:54:20 2008 -0400
+++ b/src/python/m5/SimObject.py Mon Jun 09 04:53:36 2008 -0400
@@ -217,7 +217,10 @@ class MetaSimObject(type):
# just declaring a pointer.
decl = 'class %s;' % _cxx_class
if namespace:
-decl = 'namespace %s { %s }' % (namespace, decl)
+namespaces = namespace.split('::')
+namespaces.reverse()
+for namespace in namespaces:
+decl = 'namespace %s { %s }' % (namespace, decl)
cls._value_dict['cxx_predecls'] = [decl]
if 'swig_predecls' not in cls._value_dict:
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
What about making Enums recognize cxx_namespace too? That would be
pretty handy although I'm not sure how feasible. There seems to be a
global list of them that would probably get confused if there was more
than one with the same name, even if they were in separate modules.
Gabe
Gabe Black wrote:
It won't, but if you use the attached patch it seems to. Let me know if
it looks good and I'll tack it onto my queue. Also, is there a solid
reason the create functions can't end up in a namespace other than the
global one? I'm ending up with some pretty horrible names trying to make
sure everything is unique.
Gabe
nathan binkert wrote:
I do think nested namespaces will work. When you do cxx_namespace,
you'd just say one::two::three
On Mon, Jun 2, 2008 at 6:59 PM, Ali Saidi [EMAIL PROTECTED] wrote:
I think Nate will have to say if Nested namespaces will work for SimObjects.
Perhaps a namespace like x86pc or something would be good for the tables.
I'm pretty sure most of that stuff is x86 only.
Ali
On Jun 2, 2008, at 9:53 PM, Gabe Black wrote:
This stuff is standardized for PCs but it might be useful for other
platforms as well. I'm not familiar enough with this stuff to really be
able
to tell for sure, but if I had to guess I'd say it's not. I was thinking of
putting it in X86ISA and then into a nested BIOS namespace.
Gabe
Ali Saidi wrote:
Take a look at how the Alpha TLB is done for how to make
SimObjects/Python happy with namespaces. The Params builder function needs
to be in the global name space.
One question is should it go in the x86 name space or in something else?
Ali
On Jun 2, 2008, at 9:32 PM, Gabe Black wrote:
I'm just starting on making the BIOSey tables and configuration
information, like the e820 map which was forcing there to be 4 gigs of
memory, available through SimObjects. There are a bunch of hierarchical
tables for, for example, the DMI information, and I'm concerned that if I
add a bunch, maybe a few dozen, new names, I'll end up either colliding
with
things that exist or making collisions more likely later on. The obvious
C++
answer to that would be a namespace, but I'm not sure the best way to do
that in this circumstance. Regularly I think the python modules idea is
supposed to take care of this, but I'm not sure how that fits with our
stuff
and some of the fancy voodoo we've got making it all work. I'm going to
try
it that way and just see how it pans out, but if anyone has any input I'd
like to hear it.
Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
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
Params: Allow nested namespaces in cxx_namespace
diff -r 4944b77f70bd src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py Mon Jun 09 02:54:20 2008 -0400
+++ b/src/python/m5/SimObject.py Mon Jun 09 04:53:36 2008 -0400
@@ -217,7 +217,10 @@ class MetaSimObject(type):
# just declaring a pointer.
decl = 'class %s;' % _cxx_class
if namespace:
-decl = 'namespace %s { %s }' % (namespace, decl)
+namespaces = namespace.split('::')
+namespaces.reverse()
+for namespace in namespaces:
+decl = 'namespace %s { %s }' % (namespace, decl)
cls._value_dict['cxx_predecls'] = [decl]
if 'swig_predecls' not in cls._value_dict:
___
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] incremental linking
Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
I quickly scanned the SCons documentation and couldn't find anything built in, but clearly the kernel does it so it can be done. Ali On Jun 9, 2008, at 5:48 AM, Gabe Black wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Also, is there a solid reason the create functions can't end up in a namespace other than the global one? I'm ending up with some pretty horrible names trying to make sure everything is unique. I don't understand the question. I don't have a problem with namespaces if that's what you're after. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] host bridge device
So this would be the PCI bus support in the north bridge for instance? Should I just arbitrarily pick a chipset and implement that, or is there something more generic? Gabe nathan binkert wrote: So as it says, it's checking bus 0 device 0 for a host bridge. Do we have a way to set that up? I can short circuit that by filling in one of the tables from the BIOS a little more, but if this is something I'm going to need to do anyway I'd rather do that. I believe that bus 0 is on the host bridge device. You're going to need to create a new device so that the PCI bus can be discovered. It shouldn't be complicated since there aren't that many registers involved. I'm not sure how complicated the linux code is for this stuff, but the BSD code isn't too bad. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
I've done some reading online and it doesn't appear that incremental linking will cut down on the link time much at all. Doing it in smaller chunks doesn't help if all the symbols end up being exported at the end. The two ways to speed it up are to (a) not include any debugging information (remove the -g flag) or (b) build various pieces as shared libraries and link them dynamically at runtime. (a) isn't probably useful for your purposes and (b) increases the difficultly of debugging the code substantially as well as requires various pieces of the simulator to be completely independent. Either way I doubt it's worth the effort. Ali On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
That makes sense to me. I can do that at some point or if you'd rather that'd be fine too. Gabe nathan binkert wrote: It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Actually, does it make sense to get rid of cxx_namespace and just make it part of cxx_type? If you're going to do a split anyway, why bother to have two variables. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] namespaces for python SimObjects
Whoever gets to it. If you don't want to do it instead of the simple patch you wrote, we can put it on the todo list. In general, that code is getting pretty messy and needs some TLC. On Mon, Jun 9, 2008 at 11:21 AM, Gabe Black [EMAIL PROTECTED] wrote: That makes sense to me. I can do that at some point or if you'd rather that'd be fine too. Gabe nathan binkert wrote: It won't, but if you use the attached patch it seems to. Let me know if it looks good and I'll tack it onto my queue. Patch looks good. Actually, does it make sense to get rid of cxx_namespace and just make it part of cxx_type? If you're going to do a split anyway, why bother to have two variables. 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
Re: [m5-dev] incremental linking
Yeah, that makes sense. We don't really have subsystems with local symbols. That said, is it faster to incremental link strip and then finish the link? I'm just curious if there are any symbols that we can automatically strip. Then again, I build debug most of the time and you wouldn't want to strip that, so... Nate On Mon, Jun 9, 2008 at 10:50 AM, Ali Saidi [EMAIL PROTECTED] wrote: I've done some reading online and it doesn't appear that incremental linking will cut down on the link time much at all. Doing it in smaller chunks doesn't help if all the symbols end up being exported at the end. The two ways to speed it up are to (a) not include any debugging information (remove the -g flag) or (b) build various pieces as shared libraries and link them dynamically at runtime. (a) isn't probably useful for your purposes and (b) increases the difficultly of debugging the code substantially as well as requires various pieces of the simulator to be completely independent. Either way I doubt it's worth the effort. Ali On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] host bridge device
So this would be the PCI bus support in the north bridge for instance? Should I just arbitrarily pick a chipset and implement that, or is there something more generic? I think that there's really only one interface for this that really matters. On alpha, there were lots of north bridge interfaces, but on x86, they still basically use the same one. Some chipsets have extensions (for secondary bridges and such), but we don't need to use those. I agree with Ali on the look at the kernel part. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] incremental linking
One thing to try maybe is Intel CC. Perhaps their linker is faster? or do they use ld? You're probably running into a I/O limitation on your laptop not a CPU problem. Ali On Jun 9, 2008, at 2:02 PM, nathan binkert wrote: Yeah, that makes sense. We don't really have subsystems with local symbols. That said, is it faster to incremental link strip and then finish the link? I'm just curious if there are any symbols that we can automatically strip. Then again, I build debug most of the time and you wouldn't want to strip that, so... Nate On Mon, Jun 9, 2008 at 10:50 AM, Ali Saidi [EMAIL PROTECTED] wrote: I've done some reading online and it doesn't appear that incremental linking will cut down on the link time much at all. Doing it in smaller chunks doesn't help if all the symbols end up being exported at the end. The two ways to speed it up are to (a) not include any debugging information (remove the -g flag) or (b) build various pieces as shared libraries and link them dynamically at runtime. (a) isn't probably useful for your purposes and (b) increases the difficultly of debugging the code substantially as well as requires various pieces of the simulator to be completely independent. Either way I doubt it's worth the effort. Ali On Jun 9, 2008, at 12:53 PM, nathan binkert wrote: Few comments. 1) I like this idea. 2) Linux explicitly exports symbols outside of an object. This seems like it would be a pain. 3) Anonymous namespaces aren't obscure. Maybe there's a way to remove these with strip. 4) It shouldn't be hard to get SCons to support this sort of thing. Nate On Mon, Jun 9, 2008 at 2:48 AM, Gabe Black [EMAIL PROTECTED] wrote: Is there some way we can make m5 link incrementally, or in other words link subsystems together independently and then as units with each other? The final linking step seems to take a long time with ld at 100% cpu usage. That makes sense when you consider it's linking a screen and a half of object files. Breaking things into smaller .os that then get linked would help because a lot of the symbols would get resolved locally and wouldn't cause a search over the all the other object modules. Even better would be to restrict the set of symbols that get linked between subsystems so the search is over a smaller space as well, as apposed to just being done fewer times, but I don't know how we could do that without specializing to one set of tools or using obscure features like anonymous namespaces. Anonymous namespaces might not even help because they hide symbols by putting them in generated unique namespaces, but the linker probably doesn't know that and would go through them all the time anyway. This isn't broken perse, but since you have to link every time you build and I'm on a slower machine it's very annoying. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ 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
