7. Simulation support

Simulator support comes in the form of machine generated the decoder/executer as well as the structure that records CPU state information (i.e., registers).

There are currently two simulators that use CGEN:

[ < ]

[ > ]

[ << ]

[ Up ]

[ >> ]

[Top]

[Contents]

[Index]

[ ? ]

7.1 GDB Simulator

Several simulators in the GDB tree use CGEN. These simulators use a combination of the CGEN-generated files, common files in the sim/common directory of GDB releases, and custom target-specific code.

There are 3 architecture-wide generated files:

‘arch.h’: Definitions and declarations common to the entire architecture.
‘arch.c’: Tables and code common to the entire architecture, but which can't be put in the common area.
‘cpuall.h’: Pseudo base classes of various structures.

Each “CPU family” has its own set of the following files:

‘cpu.h’: Definitions and declarations specific to a particular CPU family.
‘cpu.c’: Tables and code specific to a particular CPU family.
‘decode.h’: Decoder definitions and declarations.
‘decode.c’: Decoder tables and code.
‘model.c’: Tables and code for each model in the CPU family.
‘semantics.c’: Code to perform each instruction.
‘sem-switch.c’: Same as ‘semantics.c’ but as one giant switch statement.

Either or both of ‘semantics.c’ and ‘sem-switch.c’ may be provided, it's up to the port to choose. ‘semantics.c’ is either to work with, one function per instruction, but ‘sem-switch.c’ uses a “computed goto” switch and is thus provides faster simulation.

NOTE: The actual file names are up to the port. The names of the files listed here are the convention. One reason to use different names is if the port is simulating different architecture variants and generates different files for each variant.

A “CPU family” is an artificial creation to sort architecture variants along whatever lines seem useful. Additional hand-written files must be provided. See section Porting, for details.