Is there any documentation on ML-RSIM ?

Yes, there is. The User Manual describes the features, system requirements and installation process and provides a short introduction on how to run simulations.

The Reference Manual provides a detailed description of the internals of both the simulator and the Lamix kernel intended for users who like to extend either one and lists all configuration parameters.

How does ML-RSIM differ from RSIM ?

ML-RSIM is based on RSIM v1.0, but extends it in several significant ways. The processor core has remained largely unchanged, with the exception of added support for accurate trap handling, privileged registers and the TLBs. Other extensions include:

On which platforms does ML-RSIM run ?

ML-RSIM is mainly developed on SPARC/Solaris, but has been ported to MIPS/Irix and x86/Linux hosts as well. The following platforms have been tested:

The Lamix kernel and any simulator applications must be compiled for the SPARC V8 instruction set and must be statically linked. Lamix compilation has only been tested with the Sun Workshop compiler, other compilers may cause problems.

How do I compile applications for simulation ?

Applications must be compiled for the SPARC v8 instruction set and must be statically linked. This can be accomplished by including the generic makefile in the apps/ directory in your application makefile. The main makefile only needs to define the variables SRC, HEADERS, LIBRARIES,, and TARGET appropriately.

Alternatively, you can set the appropriate compiler flags and not use the generic makefile. For Sun's Workshop compiler,
-dn -xarcgh=v8 is sufficient to produce statically linked 32-bit binaries.

Do I need to link any special libraries to my applications ?

Usually not. We have tested the native Solaris C-library as well as the GNU library.

However, for some libraries Solaris does not provide static versions and linking your application will fail. One of these libraries is libposix4 and hence Lamix provides a static equivalent that can be found in the lamix/ directory. It is fully compatible with the dynamic Solaris version.

While libsocket itself can be statically linked, it has dependencies on routines that eventually require linking of a dynamic library, and hence applications using sockets can not be linked statically in Solaris. Lamix provides its own version of libsocket that does not include these routines and allows static linking. It also implements system call stubs for the routines gethostbyname and gethostbyaddr that allow Lamix applications to perform hostname lookups despite the absence of dynamic linking. Note that normally these routines are not system calls and applications using them can not execute on native Solaris hosts.

How fast is ML-RISM ?

That depends. On an SGI Origin we have observed slowdowns in the range from 2000 to 5000, with an average of about 4000 host cycles per simulated cycle. In general, simulator speed is dominated by the processor model, but high activity of other parts such as I/O devices, or memory controller can lead to additional slowdown. On a 900 MHz Sun Blade-1000, simulations run at 9000-12000 cycles per second.

How well does ML-RSIM work on Linux ?

It appears to work stable, but there are two reasons the Linux is different. First, x86 machines use a different byte ordering than SPARCs, and since the simulator models a SPARC instruction set all memory references must be byteswapped. Generally, the simulator stores data in main memory in SPARC order, while CPU registers and other internal information is in the native format. Even careful byteswapping can cause problems for some combinations of integer and FP loads or stores to the same location.
Second, Linux is not exactly System-V compatible, so some of the simulator traps that rely on host system calls require more complex conversion of parameters. This portion has been well tested, but there is always a chance something does not work on some system.
In November of 2003 a patch was released that deals with a problem in the getdents() simulator trap on Linux hosts. It is suggested to apply this patch if simulations on Linux are desired.

What about all those patches ?

The Updates page contains an up-to-date list of patches for ML-RSIM, both the simulator and Lamix kernel. Some of these patches address problems in the code, others add features that we feel are useful to users. These patches are not included in the original distribution, so users can apply only the patches they desire. In general, it is recommended to apply patches in chronological order, and not to skip a patch.

Do you have an up-to-date version available ?

Yes, take a look at the Current Download page. This page always contains the latest stable version of ML-RSIM, it is basically the original release with all patches applied. All changes made to the current release are also made available as patches so that existing users can keep their copy up-to-date. New users can either download the latest version, or the original release and then apply all patches.

If you download the current release, make a note of the release date listed on the Current Download page or in the README file in the base directory to be able to correctly apply later patches.

Can I use ML-RSIM to do X, Y or Z?

Possibly! Although ML-RSIM provides a lot of detail and records various statistics, it is unlikely that it offers exactly what you need for your experiments. Think of ML-RSIM as a starting point. It simulates SPARC code at the cycle level, accounts for resource contention, latencies and concurrency and comes with a kernel. You can add more statistics, improve, change and add hardware models, modify the kernel and run your favorite applications.

It doesn't work, what should I do?

There are many possible causes for problems running the simulator. First, check the log file for simulator progress and error messages. This file should show the progress of booting the kernel and eventually loading the application. Any error messages along the way indicate a problem.

If nothing appears in the log file except warnings that parameter file is not found, try copying one of the rsim_params files from the distribution into your working directory. The simulator does not like having no configuration information, even though it should.

Try running one of the provided sample applications. Try running with a precompiled Lamix kernel, available on the web site.

If it still doesn't work, feel free to send us a detailed description of the problem, including details about the compiler, as well as the log-file and we will try to help you out.

Where can I get help ?

You should join the ML-RSIM-USERS mailing list by visiting the mailing list home page.
You can also email the developers directly at mlrsim@cs.utah.edu

How did ML-RSIM evolve from RSIM ?

The following is a brief history of how ML-RSIM came to be:

Sometime around 1998, the Impulse Research Group at the University of Utah chose RSIM as the base code for its architectural research on adaptive or intelligent memory systems. The directory structure was modified, and several pieces of code were re-written and optimized, primarily by Lixin Zhang. Most of the system past the D-cache interface was stripped off and replaced by a detailed system bus, memory controller, and DRAM model to more accurately model current systems. That simulator is commonly called URSIM, for Utah-RSIM.

Also in 1998, Lambert Schaelicke split off a copy of URSIM, and called it L-RSIM. This branch added a TLB, an instruction fetch stage and instruction cache, eliminated the need for predecoding binaries before passing them to the simulator, added I/O devices such as a PCI bus model, a SCSI disk controller model, a SCSI disk model and implemented a NetBSD-based kernel to run on the simulator.

URSIM also continued to improve, also adding a TLB and an instruction cache, thus eliminating the predecode step. URSIM eventually switched from the SPARC to the MIPS instruction. URSIM now also has support for privileged instructions, and has its own micro-kernel running on the simulator.

In 2000, Mike Parker began contributing to L-RSIM with an early version of the instruction fetch queue. Later contributions include Linux/x86 support, in addition to a handful of other changes. This branch became known as ML-RSIM. The ordering of the M & L in ML-RSIM isn't meant to imply a level of contribution. It only indicates the order in which these branches occurred and it sounds better than LM-RSIM.

Currently, a branch of ML-RSIM is under development to add SMT support to the processor. ML-RSIM-SMT will be kept consistent with ML-RSIM, and hopefully in due time the code trees will join once again.