#
11283:4cc8b312f026 |
|
20-Jul-2015 |
Tony Gutierrez <anthony.gutierrez@amd.com> |
ruby: slicc: have a static MachineType
This patch is imported from reviewboard patch 2551 by Nilay. This patch moves from a dynamically defined MachineType to a statically defined one. The need for this patch was felt since a dynamically defined type prevents us from having types for which no machine definition may exist.
The following changes have been made: i. each machine definition now uses a type from the MachineType enumeration instead of any random identifier. This required changing the grammar and the *.sm files. ii. MachineType enumeration defined statically in RubySlicc_Exports.sm. * * * normal protocol fixes for nilay's parser machine type fix
|
#
11282:afdcebd314be |
|
20-Jul-2015 |
Tony Gutierrez <anthony.gutierrez@amd.com> |
ruby: slicc: remove support for single machine, multiple types
This patch is imported from reviewboard patch 2550 by Nilay. It was possible to specify multiple machine types with a single state machine. This seems unnecessary and is being removed.
|
#
9773:915be89faf30 |
|
25-Jun-2013 |
Nilay Vaish <nilay@cs.wisc.edu> |
ruby: profiler: lots of inter-related changes The patch started of with removing the global variables from the profiler for profiling the miss latency of requests made to the cache. The corrresponding histograms have been moved to the Sequencer. These are combined together when the histograms are printed. Separate histograms are now maintained for tracking latency of all requests together, of hits only and of misses only.
A particular set of histograms used to use the type GenericMachineType defined in one of the protocol files. This patch removes this type. Now, everything that relied on this type would use MachineType instead. To do this, SLICC has been changed so that multiple machine types can be declared by a controller in its preamble.
|
#
9745:884ad4638236 |
|
09-Jun-2013 |
Nilay Vaish <nilay@cs.wisc.edu> |
ruby: stats: use gem5's stats for cache and memory controllers This moves event and transition count statistics for cache controllers to gem5's statistics. It does the same for the statistics associated with the memory controller in ruby.
All the cache/directory/dma controllers individually collect the event and transition counts. A callback function, collateStats(), has been added that is invoked on the controller version 0 of each controller class. This function adds all the individual controller statistics to a vector variables. All the code for registering the statistical variables and collating them is generated by SLICC. The patch removes the files *_Profiler.{cc,hh} and *_ProfileDumper.{cc,hh} which were earlier used for collecting and dumping statistics respectively.
|
#
9298:9a087e046c58 |
|
15-Oct-2012 |
Nilay Vaish <nilay@cs.wisc.edu> |
ruby: allow function definition in slicc structs This patch adds support for function definitions to appear in slicc structs. This is required for supporting functional accesses for different types of messages. Subsequent patches will use this to development.
|
#
7542:49327b849c7f |
|
20-Aug-2010 |
Brad Beckmann <Brad.Beckmann@amd.com> |
slicc: Consolidated the protocol stats printing
Created a separate ProfileDumper that consolidates the generated stats for each controller of a certain type.
|
#
6877:2a1a3d916ca8 |
|
29-Jan-2010 |
Steve Reinhardt <steve.reinhardt@amd.com> |
ruby: Make SLICC-generated objects SimObjects. Also add SLICC support for state-machine parameter defaults (passed through to Python as SimObject Param defaults).
|
#
6714:028047200ff7 |
|
05-Nov-2009 |
Steve Reinhardt <steve.reinhardt@amd.com> |
slicc: tweak file enumeration for scons Right now .cc and .hh files are handled separately, but then they're just munged together at the end by scons, so it doesn't buy us anything. Might as well munge from the start since we'll eventually be adding generated Python files to the list too.
|
#
6657:ef5fae93a3b2 |
|
22-Sep-2009 |
Nathan Binkert <nate@binkert.org> |
slicc: Pure python implementation of slicc. This is simply a translation of the C++ slicc into python with very minimal reorganization of the code. The output can be verified as nearly identical by doing a "diff -wBur".
Slicc can easily be run manually by using util/slicc
|