The mimosa regression test suite contains approximately 30 different tests which individual attempt to test some subset of Cedar/Mesa language features. The tests are of the flavor "do something, check the results and yell if they are different." Each multiple file test has a config named XMesa<TestNo>.config. This config imports RunRegressions and any other pieces required to run the test.

Nearly every test makes use of the interface XMesaProcs and OSOps to do input, output and to do basic system level things. A few implementations of OSOps exist so that the regressions can be run in any world. The top-level Regressions.config at this time is configured for use in the PCR-based world. Most tests print their name at startup time and say "Done" when they complete. Errors are printed as they occur.

Several tests are only compiled to assure compiler correctness. These are tests 20, 21, 24, 25, 26, and 28.

The regression test includes a few source-less mobs that are used with various tests.

The current design of the regressions makes it easy to run in a Commander or a PCR command interpretor and facilitates porting by factoring the regressions in such a way as to reduce dependencies. Each test in its mainline code, registers itself with a call to RunRegressions.RegisterTest. Then, based on the implementation of RunRegressions at some later time this procedure is called. Currently, the only implementation of RunRegressions is RunRegressionsInCommanderImpl. Implementing a version for the PCR command interpretor would be trivial.

Several commands are registered by RunRegressionsInCommanderImpl with the commander. They are RunAllRegressions, RunARegression, and ListRegressions. They are all self-explanatory.

The name of top-level DF is Regressions.df. Note that the name is not Regressions-Suite.df. The Regressions df uses Regressions-RS6000.df and Regressions-Sun4.df which have entries for the mob, c2c, and o's. The Regressions-RS6000.df and Regressions-Sun4.df never need to be smodeled as far as we're concerned as there is no need or desire to keep any derived objects. Do smodel Regressions.df when making changes there. (Thanks to Jim for de-mystifying/forcing makedo to do the "right thing")

Inside of the Regressions.df you will find several cm scripts. There are two flavors of scripts for both the RS6000 and Sun (for four total). The flavors are NonThreadedWorld and ThreadedWorld. Appropriate configs go will these. (Regressions.config and RegressionsNonThreadedWorld.config) To build the regressions just execute the appropriate script. This will build mach/Regressions.c2c.o or mach/RegressionsNonThreadedWorld.c2c.o which can then be loaded into a commander.

The RunAllRegressions, RunARegression, and ListRegressions are registered by RunRegressionsInCommanderImpl. RunAllRegressions, RunARegression, and ListRegressions all do pretty much what you would expect. RunAllRegressions is typically a quick and easy way to test the compiler.

In addition to the these tests, there exist some non-runnable regressions. They are compile-only tests. They can be tested using the MakeRegressionsOther.cm. Appropriate messages are echo'ed to tell you what to expect.

The "new style" regression tests have names of the form "RegressX", where X is the feature set to be tested. They depend on the RegressUtils interface (and the RegressUtilsImpl module) for reporting test results.

Each module registers a procedure under a given name. Regressions can be called by supplying a matching pattern (all regressions are run when "*" is used as the pattern) to the regress command, which is implemented in RegressUtilsImpl.

This support is currently incomplete, but will be expanded in the near future.