Tracing tools are used widely to help analyze, design, and tune both hardware and software systems. This paper describes a tool called Shade which combines efficient instruction-set simulation with a flexible, extensible trace generation capability. Efficiency is achieved by dynamically compiling and caching code to simulate and trace the application program. The user may control the extent of tracing in a variety of ways; arbitrarily detailed application state information may be collected during the simulation, but tracing less translates directly into greater efficiency. Current Shade implementations run on SPARC systems and simulate the SPARC (Versions 8 and 9) and MIPS I instruction sets. This paper describes the capabilities, design, implementation, and performance of Shade, and discusses instruction set emulation in general.

Copyright 1991, Association for Computing Machinery, Inc. Reprinted by permission. This paper originally appeared in Proceedings of the Fourth International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS), Santa Clara, California, April 8-11, 1991. The dynamic instruction counts on MIPS and SPARC are compared using the SPEC benchmarks. MIPS typically executes more user-level instructions than SPARC. This difference can be counted for by architectural differences, compiler differences, and library differences. The most significant differences are that SPARC's double-precision floating point load/store is an architectural advantage in the SPEC floating point benchmarks while MIPS's compare-and-branch instruction is an architectural advantage in the SPEC integer benchmarks. After the differences in the two architectures are isolated, it appears that although MIPS and SPARC each have strengths and weaknesses in their compilers and library routines, the combined effect of compilers and library routines does not give either MIPS or SPARC a clear advantage in these areas.

Concurrent C, a superset of C providing parallel programming facilities, is considered. A uniprocessor version of Concurrent C was first implemented. After experience with this version, the Concurrent C implementation was extended to run on two types of multiple processor systems: a set of computers connected by a local area network (the distributed version) and a shared-memory multiprocessor (the multiprocessor version). Experience with implementing and using these versions of Concurrent C is described. Specifically, the language changes triggered by the multiple processor implementations, some sample programs, a comparison of the execution times on various systems, and the suitability of these multiple processor architectures are discussed.>