Quoting nathan binkert <[email protected]>:
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<bool> 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
[email protected]
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
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
