History log of /gem5/src/mem/slicc/ast/MachineAST.py
Revision Date Author Comments
# 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