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 (simplescalar@cs.wisc.edu, contact dburger@cs.wisc.edu to join the list), if that does not work then e-mail Doug Burger (dburger@cs.wisc.edu) or Todd Austin (taustin@cse.ogi.edu).
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:
Fortunately, all variations are very small, on the order of a few thousand instructions at the most.
Perhaps you did not modify the first line of the script, change it to indicate where your Perl executable is located.
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).
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.
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.
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.
There have been four approaches to validating the results produced by SIM-OUTORDER:
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.
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".
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.
Yes, the simulators and binutils from 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:
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.
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.
SimpleScalar/x86 only works on Linux/x86 and it only supports functional simulation. This codes was written by Steve Bennett (sbennett@ichips.intel.com), contact him for more information. This code is not supported.
Page last updated on 06/23/98 by taustin@cse.ogi.edu.