> On Oct. 16, 2015, 3:15 p.m., Nilay Vaish wrote:
> > util/systemc/stats.cc, line 79
> > <http://reviews.gem5.org/r/3132/diff/3/?file=50335#file50335line79>
> >
> > The file name can be kept as constant, but at least pass an argument to
> > this function that specifies the file path.
> > I would prefer if you use the same output directory that the rest of
> > the system is using.
>
> Abdul Mutaal Ahmad wrote:
> are you suggesting to use OutputDirectory class and get the current
> directory create a stats file there. As far as I know the current management
> of stats is wrapped inside the python calls
>
> Nilay Vaish wrote:
> Forget about using the OutputDirectory class for the time being. Is it
> at all possible for statsDump
> to receive a file path in which statistics are going to be dumped? I
> would not assume that m5out
> directory is present in cwd.
>
> Abdul Mutaal Ahmad wrote:
> It is possible but that will eventually need some changes in
> statistics.cc/statistics.hh . statsDump and statsReset are handlers and they
> are registered with statistics using registerHandlers defined in
> statistics.hh. I don't think it's a good solution beacuse it will disturb the
> python calls for normal gem5 run.
As the whole contents of util/systemc is intended to be just an example of how
to construct a top level to use the .ini loading mechanism within a 'foreign'
SystemC simulation, I'd suggest passing a filename down from main.cc as it's
not unlikely that the user of this example would have their own, application
specific, ideas about where the stats file should end up that doesn't sensibly
involve reusing any of the Python mechanisms.
Perhaps add a global string variable to stats.{hh,cc} in the first instance and
set it from main.cc (to make the point about that the files other than main.cc
should be progressing towards being a SystemC interfacing library with main.cc
as a user of that library).
Looking at the registerHandlers mechanism. I think perhaps that should be
changed to use a 'DumpOperations' class. An object of a derived class of
DumpOperations can then be registered with registerHandlers. Call made on that
object to reset/dump stats can then be made rather than on raw function
pointers (mea culpa (I think)). With an object handling stats dumping, local
data could then be held (including a filename). Maybe that should be a second
step in another patch?
- Andrew
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3132/#review7382
-----------------------------------------------------------
On Oct. 16, 2015, 1:46 p.m., Abdul Mutaal Ahmad wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3132/
> -----------------------------------------------------------
>
> (Updated Oct. 16, 2015, 1:46 p.m.)
>
>
> Review request for Default.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> In previous versions of systemC-gem5 coupling statistics were not updated for
> the systemc-gem5 simulation. systemC-gem5 simulation only need the previously
> built config.ini file and normal gem5 simulation has to be run once to
> generate config.ini file. Thus stats.txt inside the m5out folder is redundant
> for systemC-gem5 simulation. A new stats file is now generated with the all
> the statistics for systemC-gem5 simulation. This will also resolve the stats
> issue in tlm-sysmtemC simulation.
>
>
> Diffs
> -----
>
> util/systemc/stats.hh UNKNOWN
> util/systemc/stats.cc UNKNOWN
> util/tlm/main.cc UNKNOWN
> util/systemc/main.cc UNKNOWN
>
> Diff: http://reviews.gem5.org/r/3132/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Abdul Mutaal Ahmad
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
