Re: [gem5-dev] Single Header File for Debug Flags

2011-06-09 Thread nathan binkert
 Well, I guess the recompilation tradeoff is worth the temporary annoyance of
 adding the specific debug flag header file everywhere.

 I'm also hoping that the new changes will allow us to eventually make
 compound flags of compound flags.
The changes are already in the tree (and have been for a while).  I
think compound flags of compound flags should work.

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


[gem5-dev] Single Header File for Debug Flags

2011-06-08 Thread Korey Sewell
What do people (mostly Nate) think about having a single header file for all
debug flags?

Instead of #include debug/MyFlag.hh for every flag you want in a DPRINTF,
you could say #include debug/debugflags.hh and that would cover all the
debug flags available for DPRINTF.

Would that (the old way?) not be more desirable then the new way of
including debug flags? Are there infrastructure things that make this
complicated?

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


Re: [gem5-dev] Single Header File for Debug Flags

2011-06-08 Thread nathan binkert
 What do people (mostly Nate) think about having a single header file for all
 debug flags?

 Instead of #include debug/MyFlag.hh for every flag you want in a DPRINTF,
 you could say #include debug/debugflags.hh and that would cover all the
 debug flags available for DPRINTF.

 Would that (the old way?) not be more desirable then the new way of
 including debug flags? Are there infrastructure things that make this
 complicated?

The whole reason I changed the flags around was to avoid the
centralized file :)  The main problem with the centralized file is
that if you add or remove a flag, you have to recompile just about
everything.  There is no reason that you couldn't do localized
includes for a set of flags though.  For example, you could add a file
to the src/cpu/inorder directory called debugflags and include the few
debug flags that you want and that way only the inorder CPU would be
rebuilt if you added a flag to it.  Adding the centralized file back
wouldn't be quite as bad as it was before since it would only be a
centralized .hh file and not a centralized .cc file (which makes doing
things like adding a flag for a unit test a real problem.)  I'm pretty
sure it's not worth it though and the localized files that include a
bunch of flags for each CPU model are probably as much as anyone
really needs.

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


Re: [gem5-dev] Single Header File for Debug Flags

2011-06-08 Thread nathan binkert
Oh, and I forgot.  Compound flags generate a header file as well.
debug/O3CPUAll.hh for example would have all of the flags that
O3CPUAll covers

On Wed, Jun 8, 2011 at 9:40 PM, nathan binkert n...@binkert.org wrote:
 What do people (mostly Nate) think about having a single header file for all
 debug flags?

 Instead of #include debug/MyFlag.hh for every flag you want in a DPRINTF,
 you could say #include debug/debugflags.hh and that would cover all the
 debug flags available for DPRINTF.

 Would that (the old way?) not be more desirable then the new way of
 including debug flags? Are there infrastructure things that make this
 complicated?

 The whole reason I changed the flags around was to avoid the
 centralized file :)  The main problem with the centralized file is
 that if you add or remove a flag, you have to recompile just about
 everything.  There is no reason that you couldn't do localized
 includes for a set of flags though.  For example, you could add a file
 to the src/cpu/inorder directory called debugflags and include the few
 debug flags that you want and that way only the inorder CPU would be
 rebuilt if you added a flag to it.  Adding the centralized file back
 wouldn't be quite as bad as it was before since it would only be a
 centralized .hh file and not a centralized .cc file (which makes doing
 things like adding a flag for a unit test a real problem.)  I'm pretty
 sure it's not worth it though and the localized files that include a
 bunch of flags for each CPU model are probably as much as anyone
 really needs.

  Nate

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


Re: [gem5-dev] Single Header File for Debug Flags

2011-06-08 Thread Korey Sewell
Well, I guess the recompilation tradeoff is worth the temporary annoyance of
adding the specific debug flag header file everywhere.

I'm also hoping that the new changes will allow us to eventually make
compound flags of compound flags.

On Thu, Jun 9, 2011 at 12:42 AM, nathan binkert n...@binkert.org wrote:

 Oh, and I forgot.  Compound flags generate a header file as well.
 debug/O3CPUAll.hh for example would have all of the flags that
 O3CPUAll covers

 On Wed, Jun 8, 2011 at 9:40 PM, nathan binkert n...@binkert.org wrote:
  What do people (mostly Nate) think about having a single header file for
 all
  debug flags?
 
  Instead of #include debug/MyFlag.hh for every flag you want in a
 DPRINTF,
  you could say #include debug/debugflags.hh and that would cover all
 the
  debug flags available for DPRINTF.
 
  Would that (the old way?) not be more desirable then the new way of
  including debug flags? Are there infrastructure things that make this
  complicated?
 
  The whole reason I changed the flags around was to avoid the
  centralized file :)  The main problem with the centralized file is
  that if you add or remove a flag, you have to recompile just about
  everything.  There is no reason that you couldn't do localized
  includes for a set of flags though.  For example, you could add a file
  to the src/cpu/inorder directory called debugflags and include the few
  debug flags that you want and that way only the inorder CPU would be
  rebuilt if you added a flag to it.  Adding the centralized file back
  wouldn't be quite as bad as it was before since it would only be a
  centralized .hh file and not a centralized .cc file (which makes doing
  things like adding a flag for a unit test a real problem.)  I'm pretty
  sure it's not worth it though and the localized files that include a
  bunch of flags for each CPU model are probably as much as anyone
  really needs.
 
   Nate
 
 ___
 gem5-dev mailing list
 gem5-dev@m5sim.org
 http://m5sim.org/mailman/listinfo/gem5-dev




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