| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
This is supposed to be deprecated, but is still used in a small way
by the tests.
Change-Id: I94fc32f9e0f03d50c00ce5421926203859064020
Reviewed-on: https://gem5-review.googlesource.com/11352
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
|
Most (but not all) of the SystemC headers are part of the "external"
interface that an existing, standard compliant module would include
through <systemc.h> or <systemc>. Since those follow slightly different
rules (relative includes, no gem5 includes), this change separates them
out so that they're easier to identify.
Also, this change moves the other files into a "core" subdirectory,
with the intention to add a "dt", aka data type, directory some time in
the future when those standard defined types are implemented.
Change-Id: Ida63f9cc0bc0431024d4dd691cc5b22b944a99a8
Reviewed-on: https://gem5-review.googlesource.com/10835
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Gabe Black <gabeblack@google.com>
|
