faq

RISC处理器仿真分析程序。可以用于研究通用RISC处理器的指令和架构设计。在linux下编译

	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 post a question to the SimpleScalar
   mailing list ([e-mail], contact [e-mail] to
   join the list), if that does not work then e-mail Doug Burger
   ([e-mail]) or Todd Austin ([e-mail]).


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
   ([e-mail]), 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.