Support Materials for the Study of Computer Architecture at UC-Davis

This web page contains information about the various software packages and tools relating to Computer Architecture research and instruction here at UC-Davis. (If you are taking ECS250A, much of this docmentation will also reside in the directory ~farrens/academic/250A/doc on the instructional machines ). See also more proj info.

NOTE - as you can tell from the reference to 250, parts of this page are a bit out of date.  I'm working on getting everything updated - I will change the reference to 250A last, so you can tell when I'm done.  Go ahead and poke around a bit - most of what is here is correct, just not everything.)

Software Packages

Benchmark Suites/Programs

Traces

Software Packages:

  • MIPS-derived Tools (including DLX)
  • Wisconsin Architectural Research Tool Set (WARTS)
  • Simplescalar:Package of simulators and compiler (gcc)
  • ATOM: Program Analysis Tool for Alphas
  • SHADE: Program tracing tools for SPARC

    • Benchmark Suites/Programs:

    These files and directories are on the academic machines in ~farrens/academic/250A/benchmarks, and on american in /2/arch/benchmarks.
  • Synthetic
  • Perfect Club
  • Linpack loops
  • Livermore loops
  • SPEC 89 Benchmark suite
  • SPEC 92 Benchmark suite
  • SPEC 95 Benchmark suite

    • Address Traces (both Data and Instruction):

  • ATUM (Address Traces Using Microcode)
  • SPUR (Symbolic Processing Using RISC)
  • MULTI (Multiprocessor Traces)
  • SPEC92
  • Information about using/processing Traces

    •  

     

    Status of Software on Various Platforms:

    Information about using and processing the Program Traces:

    (Note - this is generic information about the traces.  Directory locations, etc. may not be current, and are probably not accessable from the instructional machines.  If you wish to work with these traces, contact me and I will give you the latest information on location, content, etc.)

    There are many address traces available, in many different formats. These traces contain the (virtual) address reference stream generated by a processor (usually a MIPS processor). The long traces are stored in a special compressed gzipped format, which requires a tool to bring back to life. These traces capture the entire reference stream of the run of the program, and are in many cases billions of references long. There are also various shorter traces, which range from time-sampled snapshots of a running program to entire runs of much smaller programs. Many of these traces are on american.cs.ucdavis.edu in /2/arch/traces, under various headings. The long trace runs of the entire SPEC92 integer suite of programs are in /net/keep1/home/farrens/rsch/traces/spec92.int, and (most of) the floating point progs are in /net/keep1/home/farrens/rsch/traces/spec92.fp. They are also on the instructional machines in ~farrens/academic/250A/traces.

    To process any of the traces, you have to know the format of the output. There are 3 main types of output produced and consumed by our various tools. Each of the types use a [ref_type address] format, where the ref_type indicates the type of memory reference and the address field contains the address of the reference. In the "aggie" format, the ref_type is an ascii '1' for an instruction fetch, a '2' for a load, and a '3' for a store. This format is human-readable, but can be substantially slower to process since there are so many more bytes involved. In the "binary" 5-byte [ref_type address} format, the ref_type is a single ascii character and indicates the type of memory reference (0 = load, 1 = store, 2 = instruction fetch), while the address field contains the 4-byte integer address of the fetch. This format is not directly readable by humans. The "dinero" format is essentially the same as the "aggie" format, except the meanings of the ref_types are different. In this format, a '0' indicates a data read, a '1' a data write, and a '2' an instruction fetch. There is a 4th format, called the "pixie" format, which is faster to process, but is probably beyond the scope of this project at this point. (I will be glad to tell you about it in person, if your are having problems with the other formats.)

    The long spec traces require special handling, because they are stored in a special way. We wrote a compression program which dramatically reduces the size of the trace, and then gzip the output of that program as well. So, to use the long traces, you need to do the following: gunzip < {tracename} | inflate [-a|-b|-d|-p] | {whatever} where {tracename} is the name of the trace you are working with, {whatever} is "more", or your cache analysis program, or whatever, and the 4 flags for the "inflate" program specify the format of the output ("aggie", "binary", "dinero", and "pixie", respectively). The source for the "inflate" program is in ~farrens/academic/250A/traces/compress.tools. I have built and tested in on the pc's - the binary is in ~farrens/academic/bin.pc.

    More about Project support tools:

    There are a number of different tools and traces available to help you do your projects. Many of them are on american in the directory /2/arch/tools/bin. Most of the programs in here are probably not of much interest to you folks, although some might be. There is also an associated directory /2/arch/tools/man, which contains man pages for most of the programs in the bin directory. (Unfortunately, due to time constraints, the documentation is often a bit sparse and/or non-existant). This bin directory contains compiled versions of many of the different tools we have written here over the years. The source for most of these programs (as well as source to other programs not in the bin directory) is in /2/arch/tools/trace.tools, and there is also some source in /2/arch/tools/warts. The "warts" directory contains the Wisconsin Architectural Research Tool Set, which includes a cache simulator (dineroIII), as well as some other stuff. There is also the ATOM suite of programs, which is extremely nice but only runs on Alphas. This tool allows you instrument a given binary and have the execution of the program call user-generated analysis routines at specified points. So, for example, if you are looking at branch prediction stuff, you can instrument a given binary to essentially trap on every branch instruction to an analysis routine you have written. This is an extremely powerful, useful, fast an flexible tool for doing research. So, as you might expect, it is also just a bit tricky to learn to use. But once you have the hang of it, boy, look out! You should also check out ~farrens/academic/250A on the instructional machines. In this directory is the distribution tape of the dlx stuff, which contains lots of stuff (source for dinero, traces, benchmarks, etc.) The simulators we have running here are also available via this directory.