Re: [m5-dev] DPRINTF changes
> I have no objections based on your description, but I'm curious what python > code is complicated enough to need DPRINTFs. Also, how would you expect the > syntax for defining traceflags to change? As for python, we keep moving stuff from C++ to python, so more and more of the framework is there. Stats is my current big example. I figured out that the syntax doesn't really have to change. Basically instead of generating a monolithic "traceflags.hh" (and cc file). I generate one per flag. This now requires that you have to add a #include "trace/FlagName.hh" in order to use a flag, but there's an awesome side benefit to this in that the entire source tree will no longer be rebuilt as a side effect of adding a flag. It was all pretty easy to do. A diff will be coming soon. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] DPRINTF changes
Quoting nathan binkert : So in debugging some python stuff, I was thinking to myself about how it would be nice if we had DPRINTF support in python, so it got me thinking about how I might implement that. It turns out that it isn't that hard since I've already exposed the flags in python, but I started to get annoyed about the fact that I have to define new flags in SConscript files. I've also recently removed almost all cases of monolithic files gathering a bunch of info from across the build (to make it easier to modularize things). So, I'd like to do this to the trace flags. Right now, we have a std::vector of all of the trace flags, and each trace flag is an index into that vector. SCons has a TraceFlag Instead, I was thinking of having Trace::Flag objects that are statically allocated and register themselves with a global dictionary of flags at runtime. I think that this should be just as fast as the existing system since each flags object would contain a bool representing if the flag is on or off. It would also have the benefit of making each TraceFlag localized from a compile perspective, so you'll no longer have to rebuild the word just because someone defined a new trace flag. Any comments or objections to this approach? I'm pretty sure that the end result will have the same DPRINTF syntax but a different syntax for defining trace flags. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I have no objections based on your description, but I'm curious what python code is complicated enough to need DPRINTFs. Also, how would you expect the syntax for defining traceflags to change? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] DPRINTF changes
So in debugging some python stuff, I was thinking to myself about how it would be nice if we had DPRINTF support in python, so it got me thinking about how I might implement that. It turns out that it isn't that hard since I've already exposed the flags in python, but I started to get annoyed about the fact that I have to define new flags in SConscript files. I've also recently removed almost all cases of monolithic files gathering a bunch of info from across the build (to make it easier to modularize things). So, I'd like to do this to the trace flags. Right now, we have a std::vector of all of the trace flags, and each trace flag is an index into that vector. SCons has a TraceFlag Instead, I was thinking of having Trace::Flag objects that are statically allocated and register themselves with a global dictionary of flags at runtime. I think that this should be just as fast as the existing system since each flags object would contain a bool representing if the flag is on or off. It would also have the benefit of making each TraceFlag localized from a compile perspective, so you'll no longer have to rebuild the word just because someone defined a new trace flag. Any comments or objections to this approach? I'm pretty sure that the end result will have the same DPRINTF syntax but a different syntax for defining trace flags. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
