Searched hist:13206 (Results 1 - 12 of 12) sorted by relevance
| /gem5/src/systemc/core/ | ||
| H A D | sc_sensitive.cc | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sensitivity.cc | 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sensitivity.hh | 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | event.hh | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sc_spawn.cc | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | event.cc | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sc_module.cc | diff 13280:3a1147706ccf Tue Oct 02 19:59:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Implement sc_hierarchical_name_exists. This function checks the top level collection of events and objects to find if one with a particular name exists. Change-Id: Icf539b502fa9c7401be907ee975eb24a47e79a87 Reviewed-on: https://gem5-review.googlesource.com/c/13206 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | SConscript | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | process.hh | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | process.cc | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| /gem5/src/systemc/ext/core/ | ||
| H A D | sc_event.hh | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | sc_port.hh | diff 13206:c944ef4abb48 Fri Sep 14 03:04:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Refactor sensitivities. Dynamic and Static sensitivities used to be represented by the same classes, even though they're (almost) disjoint in how they worked. Also timeouts, which can be used alongside dynamic sensitivities, were handled by the sensitivities themselves. That meant that the sensitivity mechanism had to mix in more types of behaviors, increasing complexity. Also, the non-standard timed_out function Accellera includes is harder to implement if the path for timeouts and regular sensitivities are mixed together. This change splits up dynamic and static sensitivities and splits out timeouts. It also immitates the ordering Accellera uses when going through sensitivities for an event. Static sensitivities are triggered first in reverse order (why?), and then dynamic sensitivities are triggered in what amounts to reverse order. To delete a sensitivity which has been handled, it's swapped with the one in the last position, and then the vector is truncated to drop it at the end. This has the net effect of stirring the dynamic sensitivities, and isn't easily immitated using a different approach, even if other approaches would be more straightforward. Double check addSensitivity for event.hh Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d Reviewed-on: https://gem5-review.googlesource.com/c/12805 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
Completed in 92 milliseconds