forked from yszheda/sim-outorder_RRIP-HP-cache
-
Notifications
You must be signed in to change notification settings - Fork 0
/
FAQ
184 lines (136 loc) · 8.15 KB
/
FAQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
SimpleScalar Frequently Asked Questions
---------------------------------------
Q: How do I ...
A: Look at the SimpleScalar Hacker's Guide in the file hack_guide.pdf, if your
question is not answered in there, then look for your question in this
FAQ, if you don't find it there, then e-mail your question to SimpleScalar
LLC ([email protected]).
Q: Why don't I get the same number of instructions/references/etc each time
I run my program?
A: It is very difficult to produce the same exact execution each time a program
executes on the SimpleScalar simulators. Many variations in any particular
execution are possible, including:
- calls to time() and getrusage() will produce different results
- redirecting output will cause subtle changes in printf() execution
- the size of your environment, which is imported into the simulated
virtual memory space, affects the starting location of a programs
stack pointer
- small variations in floating point across platforms can effect
execution
Fortunately, all variations are very small, on the order of a few thousand
instructions at the most.
Q: Why don't the perl scripts work?
A: Perhaps you did not modify the first line of the script, change it to
indicate where your perl executable is located.
Q: What is instruction address compression?
A: Address compression (via the -icompress flag on sim-cache and sim-outorder)
linearly scales text reference addresses from the 64-bit instruction domain
to a comparable address produced by 32-bit instructions. We support this
option because the base SimpleScalar instruction set definition does fit
into a 32-bit encoding, but it has been encoded into 64-bits to ease
modification and addition of new instructions. This option is useful when
unified cache levels are employed (without unified cache levels, simply
doubling the block size of the I-caches will have the same effect).
Q: Whenever I try to run binaries, I always get the error: "binary endian does
not match host endian", what is wrong?
A: Your binaries are the wrong endian! Either you mis-configured GCC, GAS
or GLD, or you grabbed the wrong binary release. Reconfigure the compilers
to the opposite endian, or get the other binary release. To determine the
endian of your host machine, run "sysprobe -s", located in the simplescalar
simulator directory.
Q: Why doesn't SimpleScalar compile on my machine?
A: We may not have tested on your platform. Fortunately, the SimpleScalar tool
set it not difficult to port, you will likely only have to modify the
simulator file syscall.c. See the documentation in syscall.h and syscall.c
for details on porting the simulator.
Q: What's the deal with that "ssbig-na-sstrix-" prefix?!?!?
A: That prefix follows the cross compiler naming format used by the GNU
compiler chain. The first prefix, "ssbig" or "sslittle" signifies the
architecture as big- or little-endian simplescalar, respectively. The
second part of the prefix "na" signifies the manufacturer, i.e., not
applicable. And the last prefix part, "sstrix", designates the operations
system, which we call SSTrix, a variant of Ultrix for the SimpleScalar
tool set.
Q: Why can't I get SimpleScalar/x86 to work?
A: SimpleScalar/x86 only works on Linux/x86 and it only supports functional
simulation. This codes was written by Steve Bennett
([email protected]), contact him for more information. This code
is not supported.
Q: How rigorously has SIM-OUTORDERS's performance been verified? What kind of
verification experiments have been done?
A: There have been four approaches to validating the results produced
by SIM-OUTORDER:
1) micro-benchmark validation, we've run a number of small
programs to test various parts of the machine, this is
why release 2 has pipetrace support, since this makes
this process easier to perform
2) correlation with independent simulators, we've done
performance validation with the multiscalar simulators,
which were developed independently over the Simplescalar
framework; when SIM-OUTORDER was configured comparable to
a dynamically scheduled stage processor, we found
comparable results, within 5% for SPEC92, we've also
compared to other published results, but this has been
less productive, since SIM-OUTORDER is more detailed than
many of the other dynamically scheduled processor
simulators on which we have published numbers
3) regression correlation, we've been careful to always run
performance regression simulation with previous versions
of SIM-OUTORDER (config/regress.cfg "dumbs down" release 2
SIM-OUTORDER to run like the release 1 SIM-OUTORDER), if
there's any deviation we track it down and fix the problem
4) code inspections, many folks at Madison, Intel, and other
schools have read the SIM-OUTORDER code to understand
how it works, this has uncovered occasional performance
bugs, and it increases our confidence that the code models
a reasonably detailed microarchitecture correctly
This is about the best it gets for a non-production machine model. Of course,
we can't ensure that the model is without bugs - use appropriate caution.
Q: Why doesn't DLite! work with sim-outorder?
A: Actually it does, but it takes a bit of practice to understand the output.
DLite! shows you the "view" of the program from the fetch stage of the
pipeline, as a result, if the fetch stage is stalled or mispredicting into
bogus memory, you'll see those "invalid memory" messages; step the simulator
a while and you'll see the instructions show up. The bottom line: it's
non-trivial to integrate a debugger with a pipeline simulator since there
are so many "views" of architected state depending on which pipestage you
examine state from. The most valuable aspects of the sim-outorder DLite!
debugger are the "mstate" commands which allow one to probe all of the state
in the pipeline. Check them out with "mstate help".
Q: How does Simplescalar exit simulation?
A: When an exit() system call occurs (implemented in syscall.c), the
implementing code makes a longjmp() to the point in main() where setjmp()
was called. That setjmp() covers a small piece of code that computes total
runtime and then it calls a stats function that dumps final statistics,
finally the simulator terminates by calling exit() for real.
Q: Has simplescalar been ported to NT?
A: Hi, the simulators and binutils from pre-release 2 builds (and passes
self test) on NT with the Cygwin32 GNU tools. I have not tried building
GCC for SimpleScalar, however.
>From README.winnt:
--
Starting in release 2.0, the simulators build under x86/WinNT. To build them,
however, you will need the following:
1) Cygnus' cygwin32 GNU tool chain release,
available from: ftp://ftp.cygnus.com/pub/gnu-win32/
2) little-endian program binaries, since the SimpleScalar GNU
GCC/GAS/GLD ports have not been re-hosted to WinNT (yet),
either 1) build the binaries on another little-endian
supported platform, or grab them from the binaries release
available from the same place you found this package
Then, follow the install instructions in the README file.
There are still some minor problems with this port; specifically, some of
the system calls made by SimpleScalar binaries have no obvious counterparts
under WinNT (e.g., getrusage()), when these system calls are made, a
warning is printed. More testing is needed, please send us any bugs/fixes
that you find if you use this port.
Steve Reinhardt ported the simulators to the WinNT/Cygnus environment.
Q: How can I use the simplescalar-2.0 stats package to print the contents of
an array.
A: Hi, use stat_reg_dist() to register an array that the stats package will
print. Unlike the scalar stats, the stats package will allocate the array,
and you should update the elements of the array using the stat_add_sample()
and stat_add_samples() functions. Sparse arrays can also be made with
stat_reg_sdist(). Look at stats.h for documentation regarding the
interfaces, and see sim-profile.c for examples of how to use these functions.
I believe that module uses just about every kind of scalar and array stat.