Applying Simulator "Warmup" Techniques in SID
Internal Specification
=============================================
The behavior described in the document sid-warmup-external-spec.txt can be
realized in SID by implementing the following:

cfgroot_component
-----------------
o Add a mapping from configuration name to configuration spec.

o Add an attribute "dynamic-config". When set with a value of the form

    <name>:<spec>

  it adds the name/spec pair to the mapping. This corresponds to the
  command line option --profile-config.

o Add an attribute "lookup-dynamic-config". When set, assume the value is the
  name of a config in the mapping and look it up. If found make the spec
  available via the "found-dynamic-config" attribute.

dynamic_config component (new)
------------------------------
o One of these is allocated for each --board. It manages the configuration of
  that --board including:
  - configuration on demand via the configuration syscall
  - configuration on function entry/exit

o This component maintains a table of configurations which have been used by
  its --board. The index of each configuration in the table is its handle.

o This component maintains a mapping of function names to config spec names.
  This mapping is established by setting the profile-functions! attribute with
  strings of the form

    <function-name>[,<function-name]*:<config-name>

  The attribute may be set more than once and will accumulate pairs in the
  mapping. This corresponds to the command line option --profile-func.

o This component maintains a list of functions which should be run in
  warmup mode. This list is established by setting the warmup-functions!
  attribute with strings of the form

    <function-name>[,<function-name]*

  The attribute may be set more than once and will accumulate pairs in the
  mapping. This corresponds to the command line option --warmup-func.

o This component maintains a function call stack containing the handle of the
  configuration to be used for each function. The correct maintenance of this
  stack depends upon the port driving the cg-caller, cg-callee, cg-jump and
  cg-return pins on function calls, branches and returns. Without this,
  the stack will not be maintained and the --profile-func and --warmup-func
  options will have no effect.

o The configuration is changed by either:
  - setting the configure! attribute with the name of a configuration spec
    known to the cfgroot component.
  - driving the configure! pin with the handle of a configuration in the table.
  - Entering or returning to a function on the function call stack.

o This component maintains a list of configurable client components. When the
  step! pin is driven and the configuration has changed, the dynamic
  configurator sets the "configure!" attribute of each client with the spec of
  the new configuration. Each client is responsible for interpreting the spec
  and reconfiguring itself accordingly.

Individual Components
---------------------
Each component which may be reconfigured inherits from the
configurable_component mix-in base class. This provides each component with
the "configure!" attribute and a virtual method

    void configure (const string &spec);

The spec will be one of

	trace-extract=true|false
	trace-semantics=true|false
	trace-disassemble=true|false
	trace-core=true|false
	trace-counter=true|false
	ulog-level=N
	ulog-mode=greater|less|equal
	wrap=<component-name>[,<component-name>]*
	verbose=true|false
	final-insn-count=true|false
	gprof=<filename>[,N]
	insn-count=N

The implementation of 'configure' for each component should:

1) Call <base_class>::configure (spec)
2) Handle the given spec, if relevent for that component and ignore it
   otherwise.

Implementation Notes
--------------------
The current implementation provides support for the SID command line options
listed above. Below are some notes regarding the implementation

o No cpu currently drives the cg-caller, cg-callee, cg-jump and cg-return pins
  on function calls, branches and returns. This functionaility has been tested
  using an internal Red Hat port.

o In order to support detection of calls and returns to individual functions,
  the elf loader component now reads the symbol table of the executable and
  supports an interface for determining which function a given address is in.

  When the loader's "function?" pin is driven, the address is checked and the
  name of the function containing that address is made available via the
  loader's "current-function" attribute.

o Since the output filename for the --gprof option may be changed dynamically,
  the gprof component has been enhanced to maintain an array of statistics, one
  entry for each output file. Using dynamic configuration, statistics for
  different parts of the application may now be output to separate files.

o In order to solve timing issues, part of the gprof dynamic configuration
  is achieved by connecting/disconnecting pin connections between the cpu
  component and the gprof component. For this reason, the gprof component is
  not registered as a client of the dynamic configurator component. The
  gprof component's dynamic configuration is triggered from the cpu
  component's 'configure' method. The cpu component sets the gprof component's
  "configure!" attribute.