SimICS Tutorial: Getting a Grip on Grep

This page gives a fairly thorough tutorial of using SimICS to study the behavior of a simple program. As an example we chose to study the GNU utility grep. We are here using version 2.0 of grep, the full distribution for which can be fetched from MIT at ftp://prep.ai.mit.edu/pub/gnu/grep-2.0.tar.gz.

You can replicate this tutorial if you fetch the SimICS examples. In it we include the grep source code, a ready-configured makefile, and a pre-compiled, dynamically linked binary, as well as this HTML file together with a shell script that should regenerate something similar to this file, if you've installed SimICS correctly. (I'll try to keep this file up-to-date; the last major overhaul of this tutorial was in May, 1997.)

Table of Contents

Getting started

Let's pretend we're looking for the usage of the function "copyset". We run grep on its own source code:

Pretty straightforward. Now lets assume that this is a good benchmark for grep, and we want to study what grep does when it searches for "copyset" in its own source code.

SimICS is an instruction-set simulator that can run ordinary Solaris (Sparc V8) binaries. It does this by emulating the effects of each Sparc instruction, one-by-one. When it encounters a system call, it attempts to emulate the effects of it. By running programs in this rather roundabout manner, SimICS allows you to do various interesting things that are difficult or impossible to do with other types of tools.

Command line mode and log files

We begin with running grep "on top of" SimICS in the simplest manner possible:

Here we've run SimICS in "command line mode". Upon seeing what appears to be a command followed by a list of arguments, SimICS will load the program, and simulate the effects of the program, passing along the various arguments. When the program exits, so does SimICS. In addition to the normal output from grep, SimICS prints a copyright notice and a small comment about a log file. The log file contains all the commands given to SimICS, including command line arguments. This log file can be used as an input script, allowing an interactive session with SimICS to be easily duplicated. SimICS will generate a new log file each time it is executed.

If we don't want the various comments and copyright information, but want to see exactly the same output as grep generates when run by itself, we can use a particular set of command-line arguments to tell SimICS to be as inconspicuous as possible:

In the example, we also suppress the generation of a log file.

Script files and processor statistics

But this is still not terribly interesting, since what goes on under the hood is all hidden away. Let's try something else. As we mentioned above, SimICS can execute from a script. The default script name is ".simics", which is read by SimICS when run running in "command line mode":

In the above example we've introduced several things at once:

Data Caches and Extensions

SimICS supports cache simulation using extensions. Extensions are dynamically loadable objects that can add features to SimICS. A principal use is to load a memory hierarchy simulator, either one you've written yourself or one that comes with the SimICS distribution.

In the SimICS distribution, at least two memory hierarchy extensions are included: generic-cache and supersparc. In this example we'll use generic-cache.

When generic-cache is loaded, pstats will show the overall cache performance of the application. Generic-cache can simulate caches with varying line size, number of lines, and associativity. You can set these values interactively. Generic-cache simulates a combined data and instruction cache. Let's try running the same test as above, but add simulation of a large cache:

Here, we're simulating a 1 megabyte, direct-mapped unified (data and instruction) cache with 64-byte lines.

Again, we've introduced some new things:

The other cache extension, supersparc, simulates the on-chip caches of the SuperSPARC processor, namely 16 kbyte 4-way set associative data cache and 20 kbyte 5-way set associative instruction cache. The supersparc extension does not simulate coherency. The benefit of a specialized cache simulator is that it is significantly faster.

For the rest of this document, we will use the supersparc cache simulator.

Unix emulation and help

SimICS internalizes emulation for a few dozen common SunOS 5.x system calls. This includes support for nasty things like fork(), exec(), mmap(), etc. This allows SimICS to create, in essence, a virtual Unix machine: As usual, we run from a script (".simics-3"), and demonstrate some commands:

Controlling the execution - breakpoints and watchpoints

A benefit of running a program on a simulator such as SimICS is that it offers very good control over the execution. SimICS allows you to set breakpoints on several types of events, including: Let's try some of these: Comments:

Inspecting state

Most of the execution state of the processor is available for inspection during simulation. This includes memory, processor state, and devices such as the translation look-aside buffer (TLB).

Comments:

Profiling

Now we're beginning to do some interesting stuff. SimICS supports profiles. A profile keeps track of which instruction causes events to happen. This can include, at a minimum, for each word in memory:

If you're running with a cache simulator extension, you will probably also have: For example:

Comments:

Of course, for large programs this can become rather unwieldly. Therefore, SimICS supports setting linear weights to each of the profiles:

Comments:

Symbolic front end - using GDB

The SimICS distribution includes a modified version of GDB 4.11 called gdb-simics. gdb-simics can support running SimICS as a back-end. You can run gdb-simics in several ways:

The later alternatives are better (i.e. running from within emacs is best). In the example below, we've chosen the second alternative. Note that the first alternative does not allow you to pass parameters directly to the program. Please also refer to the gdb-simics README file for hints on usage.

gdb-simics can basically do everything GDB 4.11 can do, in addition to the features in SimICS. Standard GDB functions, such as single stepping, setting and clearing breakpoints, etc, are transparently translated to SimICS commands. gdb-simics and simics-backend share the same command line: any command that GDB doesn't understand, it passes on to SimICS. You can force a command to be passed to SimICS by using the sim command.

Comments: That wraps up our SimICS tutorial. Thanks for reading this far. If you have any suggestions for this page, please let us know.

This web page has been generated automatically from running this script. It was generated on Sun May 25 15:18:18 MET DST 1997 and the SimICS version used was SimICS Alpha 0.9 (Sun May 25 15:12:38 MET DST 1997) .

Written by Peter Magnusson, send comments and questions to simics-bug@sics.se.
Copyright (c) SICS, 1991-1997, All Rights Reserved