From gordoni@lunarbase.cs.adelaide.edu.au Sat Nov 7 00:56:51 1992 To: comp.arch From: gordoni@lunarbase.cs.adelaide.edu.au (Gordon Irlam) Newsgroups: comp.arch Subject: SPA: pixie for Sparc architecture Date: 7 Nov 92 00:56:51 GMT Reply-To: gordoni@cs.adelaide.edu.au Organization: Sun Microsystems Inc., Mountain View, CA > 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.