74 lines
2.5 KiB
Text
74 lines
2.5 KiB
Text
This directory contains two very different simulators:
|
|
|
|
o gencode (old)
|
|
|
|
Gencode.c outputs a single monolithic file that is
|
|
#included by interp.c
|
|
|
|
o igen (new)
|
|
|
|
The *.igen files are used as inputs to ../igen/igen.
|
|
A number of separate, fairly modula files, are created.
|
|
|
|
The new simulator has a number of advantages:
|
|
|
|
o builtin support for multi-simming (single simulator
|
|
image supporting a number of different instruction
|
|
set architectures).
|
|
|
|
o Easier maintenance. The input files are not confused
|
|
by an intermixing with the generator code.
|
|
|
|
gencode continues to exist so that old architectures can be emulated.
|
|
*.igen should be used when adding new architectures or adding
|
|
instructions to an existing ISA.
|
|
|
|
Known bugs?
|
|
|
|
In mips.igen, the semantics for many of the instructions were created
|
|
using code generated by gencode. Those semantic segments could be
|
|
greatly simplified.
|
|
|
|
|
|
----
|
|
|
|
Old README.Cygnus ...
|
|
|
|
> README.Cygnus
|
|
-------------------------------------------------------------------------------
|
|
|
|
The following are the main reasons for constructing the simulator as a
|
|
generator:
|
|
|
|
1) Avoid large fixed decode source file, with lots of #ifs controlling
|
|
the compilation. i.e. keep the source cleaner, smaller and easier
|
|
to parse.
|
|
|
|
2) Allow optimum code to be created, without run-time checks on
|
|
instruction types. Ensure that the simulator engine only includes
|
|
code for the architecture being targetted. e.g. This avoids
|
|
run-time checks on ISA conformance, aswell as increasing
|
|
throughput.
|
|
|
|
3) Allow updates to the instruction sets to be added quickly. Having a
|
|
table means that the information is together, and is easier to
|
|
manipulate. Having the table generate the engine, rather than the
|
|
run-time parse the table gives higher performance at simulation
|
|
time.
|
|
|
|
4) Keep all the similar simulation code together. i.e. have a single
|
|
place where, for example, the addition code is held. This ensures that
|
|
updates to the simulation are not spread over a large flat source
|
|
file maintained by the developer.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
To keep the simulator simple (and to avoid the slight chance of
|
|
mis-matched files) the manifests describing an engine, and the
|
|
simulator engine itself, are held in the same source file.
|
|
|
|
This means that the engine must be included twice, with the first pass
|
|
controlled by the SIM_MANIFESTS definition.
|
|
|
|
-------------------------------------------------------------------------------
|
|
> EOF README.Cygnus
|