We were supposed to do one update phase before adding all processes
which didn't have dont_initialize() called to the run queue. We were
doing that in the opposite order.
Change-Id: I6dd4108040d455dc78029da029a2eb5e7af819cb
Reviewed-on: https://gem5-review.googlesource.com/c/14915
Reviewed-by: Matthias Jung <jungma@eit.uni-kl.de>
Maintainer: Gabe Black <gabeblack@google.com>
This is a reasonable size for a stack, and the default size for a stack
on Linux as determined by some quick Googling. The sc_main fiber would
normally use the primary program stack if run under the standard
systemc implementation, and so might expect to have more room to play
with.
Change-Id: Ie12344939e7b249da203630ebc7dc773a387d716
Reviewed-on: https://gem5-review.googlesource.com/c/14396
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
Some build failures has been seen after USE_SYSTEMC being True by
default and that has been caused by double definition of _XOPEN_SOURCE
and _POSIX_C_SOURCE in some python versions (like 2.7.5, 2.7.13) and
/usr/include/features.h (used by gcc)
Python definition should preceed features.h one, since the latter will
manually #undef them before #define them.
Change-Id: I774711aaf8145df9ad7677a393a60cf3662d6816
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/14095
Maintainer: Gabe Black <gabeblack@google.com>
Now that that's managed in c++, we can do that directly without having
to depend on the python code being available, the code which lets us
call from c++ to python, or for the embedded python interpretter to
have started running and have loaded the appropriate modules.
Change-Id: Ied110d8f22181095f8c0c645636a9bd67964263e
Reviewed-on: https://gem5-review.googlesource.com/c/14056
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
By pulling out the sc_main fiber (scMainFiber), we can make it
available to different entities in the simulator and avoid having to
have parallel bookkeeping.
Also this will make it possible to hook into sc_main without putting
the code in sc_main.cc.
Change-Id: I7689441424238e9b2e4d2b48e945dea35fd8cc5d
Reviewed-on: https://gem5-review.googlesource.com/c/13977
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
The previous implementation dereferenced a null pointer to create a
reference which would then have its address taken in the sc_bind_proxy
constructor. clang says that that uses undefined behavior, so this
change adds a default constructor which initializes the two contained
pointers to null explicitly.
We have to hope systemc code doesn't play around with sc_bind_proxy too
much and doesn't accidentally use this constructor unintentionally, but
it seems like the least bad possible solution which makes clang happy.
Change-Id: Ic59603495fe7a406586a18ce44de979f84089bcd
Reviewed-on: https://gem5-review.googlesource.com/c/13879
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These warnings were removed when the functionality they warned about
was implemented, but there were some leftovers like unnecessary
includes and some helper functions which hid gem5 specific headers
from the ext directory.
Change-Id: Ic886ac0f1264687524e3a7b7eaab8836f318a5a2
Reviewed-on: https://gem5-review.googlesource.com/c/13398
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is to avoid having to expose the scheduler (which tracks the
current process) to header files which should be independent of gem5
and the underlying implementation.
Change-Id: I1b0810ab66c3ce52b5b94236d7df86da66a62472
Reviewed-on: https://gem5-review.googlesource.com/c/13335
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
STL containers may need to be constructed before they're used. Don't
count on being able to insert into them during a static initializer.
Change-Id: Icb05d5084a470e1ebd976ae6e1954b1a78aabd6a
Reviewed-on: https://gem5-review.googlesource.com/c/13329
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
There's a deprecated reporting mechanism based on integer message ids,
and the reporting mechanism needs to be refactored a bit to make it
easier to support.
Some bookkeeping data structures were moved out to somewhere they
can be accessed by other code, obviating the non-standard get_handler
function.
Change-Id: Id427cd79be9ef0f3275fbac39ff047ab672fb3e0
Reviewed-on: https://gem5-review.googlesource.com/c/13318
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
When resetting a process which is ready pending coming out of suspend,
clear that state since the process is about to run in service of the
reset.
Change-Id: Iade3ec4b2f3eadd372cce456dca66850d37ed5fd
Reviewed-on: https://gem5-review.googlesource.com/c/13316
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
For some reason lost to the sands of time, the throw_it function was
virtual for the Thread class, and that class would call the base
class's throw_it, and then also injectException itself. That would
result in the exception being injected into the thread twice which is
incorrect.
Since it's not clear what the original intention of this code was, the
throw_it function is now no longer virtual, and the one useful aspect
of it, a check if the process is already terminated, was moved into the
base class function.
Change-Id: I7fb14baa7728bd1e9206011870b6ccaa9c4e8c64
Reviewed-on: https://gem5-review.googlesource.com/c/13312
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
If an exception escapes sc_main, Accellera catches it and feeds it
into the report handler, telling it to run the catch actions. This
seems like it sets up lots of dangerous scenarios, and also makes a
vital error detecting path more complex and error prone.
On the other hand, it makes one of the tests pass.
Change-Id: I7f9d07e01e63c7abeee903febe2e434041ec49a4
Reviewed-on: https://gem5-review.googlesource.com/c/13307
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These are used in one of the tests, specifically the comma operator. It
didn't cause compilation to fail because of the default meaning of the
comma.
Change-Id: I7ce7fe74f02d4ad6a4ab896a2f0d6bd1ce635c2f
Reviewed-on: https://gem5-review.googlesource.com/c/13298
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Positionally binding more than once (like with the deprecated comma or
<< operators) should pick up where it left off the last time instead
of starting again from the beginning.
Change-Id: Ifc33520d6ce40544bd0ad80a5657b1a38a7914e4
Reviewed-on: https://gem5-review.googlesource.com/c/13297
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The previous implementation used the value changed event to track when
signals changed value, but there were a couple problems with this
approach. First, this piggybacked on the sensitivity mechanism in some
ways, but diverged in others. The sensitivity didn't notify a process
when it was satisfied like other sensitivity types would, and it also
ignored whether the process was disabled.
Second, the value_changed_event is notified by a signal instance as a
delta notification, but reset signals are supposed to act immediately.
That means they should happen before all delta notifications, or in
other words all delta notifications should see the reset status of a
given process. That's particularly important in the case of wait(int n)
where setting the reset clears the reset count, and the count is
checked when determining whether or not to wake up a process when its
sensitivity is satisfied, potentially by a delta notification.
Third, by removing the middle man and not trying to repurpose the
sensitivity mechanism, the code gets simpler and easier to understand.
Change-Id: I0d05d11437291d368b060f6a45a207813615f113
Reviewed-on: https://gem5-review.googlesource.com/c/13294
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It appears that events which are triggered during the timing phase
are considered triggered in the following evaluation phase. The
"triggered()" function on events is non-standard and not really
explained anywhere, but this appears to work in practice.
Change-Id: I2574dc4569bf148c55fbe2a4873d458fc507f2a5
Reviewed-on: https://gem5-review.googlesource.com/c/13293
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The standard says that there are namespaces for each module, and
one global namespace. Accellera also has namespaces for each process,
which shows up in the test output.
Change-Id: I4c8c5cecd5fb685d7bab521d9ae131aef23a6ab4
Reviewed-on: https://gem5-review.googlesource.com/c/13291
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Because SC_REPORT_ERROR usually causes an exception to be thrown, it's
easy to assume it will be the last thing executed in a function. It
might, however, be set up to do nothing, in which case the function
will continue to execute.
This change makes sure sc_prim will be set up properly even if errors
about the time a channel can be set up are ignored.
Also, if an exception is thrown while sc_port is being set up, the
corresponding Port object needs to be cleaned up. Rather than try to
intercept exceptions in the constructor and clean up properly, we'll
just make the allocation of the Port object be the last thing it does.
If the function exits early, then the Port pointer will still be
nullptr and nothing will need to be done.
Change-Id: If8f6f6b7e6830235fee3cd75625240b99e87dfbe
Reviewed-on: https://gem5-review.googlesource.com/c/13289
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make it the end of "before_end_of_elaboration" rather than the end
of "end_of_elaboration". This interpretation fits the behavior expected
by some of the tests.
Change-Id: I3f589147834ab5d5dc8c0e9b4849dd00491c5848
Reviewed-on: https://gem5-review.googlesource.com/c/13287
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
