Hi folks. I was trying out the gem5-within-systemc build since I apparently
broke it when I moved the util/systemc code into a subdirectory, and I
noticed two things:

1. Building the gem5 library with native systemc support will probably
conflict with the Accellera version when those are linked together. The
instructions should tell people to disable that support when building that
library.

2. Building the native systemc support without python enabled fails to
compile.

When looking at the python dependence in systemc, there are three places
where it crops up. First, there are some optional linkages which make it
possible to call sc_main from python. Those can be moved into their own
file and guarded with the appropriate checks in the scons files.

Second, the start of python is being used as a way to ensure that a
structure which keeps track of predefined error messages has been
constructed before it's populated. This could be fixed, I think, by using a
function which declares that structure statically and returns a reference
to it. That way, when you call that function, that structure will be
initialized right then, and you'll know it's ready to use. That forces a
particular order for static initializers which removes the dependence on a
later event to key off of.

Third, the code that keeps track of whether the time resolution has been
fixed is only in python, and so the systemc C++ code needs to call into
python to access that functionality. I think that should be moved into C++
so that that will work without having to jockey back and forth into python,
or even to have to invent some alternative if python isn't available.

Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to