Commit | Line | Data |
---|---|---|
13151a93 AC |
1 | This directory contains two very different simulators: |
2 | ||
3 | o gencode (old) | |
4 | ||
5 | Gencode.c outputs a single monolithic file that is | |
6 | #included by interp.c | |
7 | ||
8 | o igen (new) | |
9 | ||
10 | The *.igen files are used as inputs to ../igen/igen. | |
11 | A number of separate, fairly modula files, are created. | |
12 | ||
13 | The new simulator has a number of advantages: | |
14 | ||
15 | o builtin support for multi-simming (single simulator | |
16 | image supporting a number of different instruction | |
17 | set architectures). | |
18 | ||
19 | o Easier maintenance. The input files are not confused | |
20 | by an intermixing with the generator code. | |
21 | ||
22 | gencode continues to exist so that old architectures can be emulated. | |
23 | *.igen should be used when adding new architectures or adding | |
24 | instructions to an existing ISA. | |
25 | ||
26 | Known bugs? | |
27 | ||
28 | A mips16 simulator cannot be built using igen. A custom mips16 | |
29 | engine.c needs to be written. | |
30 | ||
31 | In mips.igen, the semantics for many of the instructions were created | |
32 | using code generated by gencode. Those semantic segments could be | |
33 | greatly simplified. | |
34 | ||
35 | ||
36 | ---- | |
37 | ||
38 | Old README.Cygnus ... | |
39 | ||
8ad57737 JSC |
40 | > README.Cygnus |
41 | ------------------------------------------------------------------------------- | |
42 | ||
43 | The following are the main reasons for constructing the simulator as a | |
44 | generator: | |
45 | ||
46 | 1) Avoid large fixed decode source file, with lots of #ifs controlling | |
47 | the compilation. i.e. keep the source cleaner, smaller and easier | |
48 | to parse. | |
49 | ||
50 | 2) Allow optimum code to be created, without run-time checks on | |
51 | instruction types. Ensure that the simulator engine only includes | |
52 | code for the architecture being targetted. e.g. This avoids | |
53 | run-time checks on ISA conformance, aswell as increasing | |
54 | throughput. | |
55 | ||
56 | 3) Allow updates to the instruction sets to be added quickly. Having a | |
57 | table means that the information is together, and is easier to | |
58 | manipulate. Having the table generate the engine, rather than the | |
59 | run-time parse the table gives higher performance at simulation | |
60 | time. | |
61 | ||
62 | 4) Keep all the similar simulation code together. i.e. have a single | |
63 | place where, for example, the addition code is held. This ensures that | |
64 | updates to the simulation are not spread over a large flat source | |
65 | file maintained by the developer. | |
66 | ||
67 | ------------------------------------------------------------------------------- | |
68 | ||
69 | To keep the simulator simple (and to avoid the slight chance of | |
70 | mis-matched files) the manifests describing an engine, and the | |
71 | simulator engine itself, are held in the same source file. | |
72 | ||
73 | This means that the engine must be included twice, with the first pass | |
74 | controlled by the SIM_MANIFESTS definition. | |
75 | ||
76 | ------------------------------------------------------------------------------- | |
77 | > EOF README.Cygnus |