Three things aren't yet implemented, waking up processes which are
sensitive to the event, triggering of events, and garbage collecting
list objects which came from expression objects.
The garbage collection aspect is problematic since there doesn't seem
to be a correct way to implement it given the constraints in the spec,
including the way that's implemented by Accellera. It's something that
will need to be dealt with at some point, but in the interest of
forward progress it's being ignored for now.
Change-Id: Ic4e3c219ff482729f1f1302ab10181a798d48041
Reviewed-on: https://gem5-review.googlesource.com/11711
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This change implements channel updates, and also reworks the scheduler
to delegate more to the gem5 event queue by taking advantage of
event priorities to ensure things happen in the right order. There's
a lengthy comment in scheduler.hh describes how that all works.
Change-Id: I5dee71b86b2e612bb720a4429f3a72e4b7c6d01f
Reviewed-on: https://gem5-review.googlesource.com/11710
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The sc_process_handle class now primarily delegates to a Process object
it points at. The Process object does book keeping as far as its
internal state, but doesn't yet have a way to run its target function
or to schedule itself or inject exceptions into its context of
execution.
Change-Id: I98389778abe29aa26e3e3a91bf02e6721acc8a9c
Reviewed-on: https://gem5-review.googlesource.com/11613
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
To avoid making it hard to change sc_object's implementation in the
future, this change keeps most of the data members out of sc_object and
keeps them in a seperate Object which is managed independently but
still matches to the sc_objects one to one.
This change also moves away from the SystemC/sc_gem5 namespace pair in
favor of sc_gem5. Having two namespaces with classes, etc, living in
both was complicating things. Having to use a namespace that doesn't
fit in one scheme or the other isn't great, but it's the lesser of two
evils.
Change-Id: Ib59c3c515ca98c7fe519c59e9fe9270304b71cc0
Reviewed-on: https://gem5-review.googlesource.com/11611
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Now that we bit the bullet and stubbed out sc_simcontext and related
functions a little bit, we can enable a couple more tests. This change
also adds in some functions the new tests expect sc_simcontext to have.
Change-Id: I00b5cc0c6eb658eb689b9c85ed171f290009768d
Reviewed-on: https://gem5-review.googlesource.com/11356
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This function is in an "implementation defined" class body in the spec,
and has a comment next to it which says "(for internal use only)" next
to it, but it is still used directly in one of the tests.
Change-Id: Ib3727c93cc531ddd31a24897291dc7e7c97c2b58
Reviewed-on: https://gem5-review.googlesource.com/11354
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This type is deprecated, but some tests still rely on it. This change
adds just enough of it to satisfy the tests, and also the several
different mechanisms for retrieving the sc_process_b which refers to
the currently active process.
Change-Id: Id122ae5df23744b5de1e1c97573412f97a73b77a
Reviewed-on: https://gem5-review.googlesource.com/11351
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These two types are supposedly only for internal use in the Accellera
implementation based on a big warning in all caps, but they still
appear in the tests and examples in that version of systemc.
Change-Id: Icfb3ffdf1e78988def5dac145172bf28f93d7d38
Reviewed-on: https://gem5-review.googlesource.com/11283
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The spec is likely wrong in this case since a lot of the other
neighboring functions are static, and the Accellera implementation and
the tests seem to assume they're static.
Change-Id: Ia12a3735497b50f8a2419a52c83ef256416e7bc5
Reviewed-on: https://gem5-review.googlesource.com/11282
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The guts of sc_event_finder are supposed to be implementation defined,
but the tests reach in and call this particular method on that class.
Change-Id: I21c18fa68ccce7bc1a13122ee3b452ecb81b713a
Reviewed-on: https://gem5-review.googlesource.com/11274
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This is in the Accellera implementation and in the regression tests.
The implementation here is a bit different than theirs in that it uses
std::unique_ptrs.
Change-Id: Id3d1ad82482b94a5d99f27e02d1e447ca1944797
Reviewed-on: https://gem5-review.googlesource.com/11255
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The Accellera implementation of sc_event has a non-standard triggered
function which returns whether or not that particular event has been
triggered in the current delta cycle. The tests call it, so we probably
need to have it.
Change-Id: I675099b65d00e09536618d4d2d707bf3c25e3bde
Reviewed-on: https://gem5-review.googlesource.com/11187
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This variable controls what happens in some situations which are left
as undefined in the spec. It's behavior is explained in a big comment
in the Accellera implementation. Since it's used in the regression
tests, we need to at least have that variable so they'll compile and
link properly.
Change-Id: I1ac4592641be3d9dd10e7bf6144704a6fac1b2d4
Reviewed-on: https://gem5-review.googlesource.com/11186
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These "impelementation defined" methods are tested by the regression
tests, so we need to have them. We might as well have the same
general interface as the Accellera implementation since nothing there
seems overly specialized for that environment.
Change-Id: Ief6567fcd9d99d3a0f526cfa3b65043b2c828efa
Reviewed-on: https://gem5-review.googlesource.com/11185
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These macros need to expand to some minimal amount of wrapping code to
make the regression tests syntactically legal and compile.
Change-Id: I0b5569704b129d9c315526fc3363ef846a1b5c65
Reviewed-on: https://gem5-review.googlesource.com/11184
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
These overloads of sc_trace take the unsigned version of some primitive
types. The compiler thought it was ambiguous how to convert an unsigned
integer value into a signed one since there were several different
functions which took signed integer parameters of various sizes.
These versions of sc_trace aren't in the standard, but they are in the
Accellera implementation and do fix building of the regression tests.
Change-Id: I26fd06d90ae6bf5fc5aed24bc2ac826ad69eee31
Reviewed-on: https://gem5-review.googlesource.com/11182
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The spec defines these constants to be macros, but the regression test
refers to them using the sc_core namespace. That breaks things because
the macros don't expand to an identifier, they expand to an expression.
This change converts the macros into enums like in the Accellera
implementation to get the regression tests to build.
Change-Id: I3db7dc87a7a597907df658624a7343bc6ca1734e
Reviewed-on: https://gem5-review.googlesource.com/11180
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The systemc spec says that sc_bind, sc_ref and sc_cref macros should
expand to boost::bind, boost::ref, and boost::cref respectively, but
that it's "use is not mandantory". Unfortunately, the regression tests
use those macros without actually including the boost headers for
themselves, and so they won't compile without dragging in these boost
headers as a dependency.
This should be mostly ok to include here since gem5 itself shouldn't
include systemc, just the sub headers that systemc brings in. systemc
code which includes systemc *will* have a dependency on boost, but that
at least contains the new dependency somewhat.
Change-Id: I1877a1b7dae2952f30a9d577d778739abbe7ac3b
Reviewed-on: https://gem5-review.googlesource.com/11178
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The iterator class needs to have some operators, etc., defined so that
tests written against it can compile correctly. The implementations
were heavily influenced by the Accellera implementation.
Also it should be noted that the systemc spec is incorrect where it
defines these classes. When implemented like they are in the
Accellera version, the versions of bind in sc_vector_assembly which
take sc_vector<T>::iterator and iterator parameters are different, and
so they can overload each other. If implemented as described by the
spec however, those types are the same and the code won't compile.
Change-Id: I62852adf7e6c0a2f3df076ba4e93d2501859c32d
Reviewed-on: https://gem5-review.googlesource.com/11177
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The standard says there's not supposed to be a default writer policy
for the sc_buffer template class, but in the Accellera implementation
there is, and the regression tests depend on it to compile.
Change-Id: I31d17617441224e86c56c54e45364be8f4f45b00
Reviewed-on: https://gem5-review.googlesource.com/10957
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
