From: gordoni@lunarbase.cs.adelaide.edu.au (Gordon Irlam)
Newsgroups: comp.arch
Subject: Re: SPA: pixie for Sparc architecture
Date: 7 Nov 1992 00:56:51 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
Reply-To: gordoni@cs.adelaide.edu.au
NNTP-Posting-Host: lunarbase

> That seems to be some kind of AI planning system -- certainly not a trace
> generator!  If anyone can tell where this really lives, I'd be grateful...

Spa is a set of tools used to analyze the performance of SPARC
binaries on the SPARCstation 1 and the SPARCstation 2.  The tools can
be used on any sun4 architecture machine running a SunOS 4 operating
system.

The tools include spy a program that traces the execution of a command
and can generate address traces, spanner a tool that converts an
address trace into an instruction count, splice a tool that combines
instruction count files, and spout a tool that displays an instruction
count file.

No modification of the binary to be analyzed is required.  Dynamic
libraries, job control, and fork/exec are all handled correctly.  Some
signal handlers may cause problems.

The Spa package does not predict overall system performance.  I/O
latency is not taken into consideration, nor is the effect of more
than one process being active at any one time.  spy does not provide
any information about the time spent handling traps, interrupts, or
system calls, nor the effects of these on the cache.

The floating point queue is not currently simulated by the Spa
package, and all floating point instructions are assumed to complete
in a single cycle.  This differs significantly from reality.

The main component of the Spa package is a SPARC simulator.  A basic
block style profiling tool is not currently included.  Consequently
the speed of this package is roughly 600 times slower than normal
execution.

The Spa package is a copyrighted work which comes with absolutely no
warranty.  It may be redistributed and/or modified under the terms of
the GNU General Public License Version 2 as published by the Free
Software Foundation.

The Spa package is available from the following locations,

    U.S. FTP:         ftp.uu.net:/systems/sun/spa-1.0.tar.Z
    U.S. UUCP:        uunet!~/systems/sun/spa-1.0.tar.Z
    Australia FTP:    ftp.cs.adelaide.edu.au:pub/sparc/spa-1.0.tar.Z

You should also get spa.diff-1.0-1.01.Z from the same location.  This
fixes a minor bug.

If you plan to hack Spa you might want to get spa-unstable.tar.Z from the
Australian site.  See the README file therein to find out why.

---------------------------------------------------------------------

You might also be interested in spix/shadow developed by Bob Cmelik
of Sun Microsystems.  This is closer to pixie in that it rewrites
the binary.  Spa currently simulates each instruction.  Consequently
spix is much faster, but has difficulty handling dynamic libaries.

Contact rfc@sun.com to order spix/shadow.  There is no charge, but
you are required to sign (in ink) a license agreeing not to sue Sun
if anything goes wrong.

---------------------------------------------------------------------

Tools for SPARC performance analysing:

prof(1).  Included as part of Sun C?
  - Requires source for sections to be profiled.
  - Displays number of times each routine to be profiled is called, and
    profil(2) based execution time estimates.
  - Compiler adds code to count routines and call to profil(2).

gprof(1).  Included as part of Sun C.
  - Requires source for sections to be profiled.
  - Displays number of times each routine to be profiled is called, and
    profil(2) based execution time estimates.
  - Compiler adds code to count routines and call to profil(2).

tcov(1).  Included as part of Sun C.
  - Requires source files to be profiled.
  - Displays number of times each source line in the files to be profiled
    is executed.
  - Compiler adds basic block counting information to the object files.

GNU versions of prof/gprof/tcov are also being developed.

Spa (gordoni@cs.adelaide.edu.au). 
  - Requires a 4.x binary.
  - Displays architectural simulation information.
  - Simulates instructions in-situ by using delayed control transfer couples.
    Passes an address trace to an analyser.

spix by Bob Cmelik (rfc@sun.com).
  - Requires a statically linked 4.x binary.
  - Displays architectural simulation information.
  - Rewrites and instruments basic blocks.

A comprehensive set of simulation tools by James Larus (larus@cs.wisc.edu).
Early versions used to be available for free, but I think this is no longer
the case.

SPARCsim (contact jting@Corp.Sun.Com).  This is a heavy weight SPARC
simulator that includes some performance analysis tools.  Expensive.
Can't handle fork/exec.  Not recommended for typical performance analysis
tasks.
  - Requires binary to be profiled.  Must be statically linked.
  - Displays instruction and cycle count data.
  - Analyzes an address trace produced by a simulator.

DSIC by David Cook (contact grossman@cs.clemson.edu).  This is a Cypress
pipeline simulator.
  - Requires assembly code for sections to be profiled.
  - Displays instruction count data for sections to be profiled.
  - Program munges assembly code to add basic block counting information.

Iprof by Steve Reiss (spr@cs.brown.edu) an instruction counting simulator.
  - Requires startup object file.  Must link statically.
  - Displays number of times each routine is called, and number of
    instructions exected by that routine, for all routines.
  - Add call to IPROFstart at start of code.  This routine rewrites the
    binary so that basic block information is gathered.