SR(1)

NAME
sr - SR compiler

SYNOPSIS
sr [-sbcqwegvOTMCFP] [-I dir] [-o file] [-d flags] file.sr ... otherfiles...

DESCRIPTION

Sr compiles programs written in the SR language. In the usual case, one or more .sr files are compiled to produce .o files, and then the SR linker, srl(1), is called to produce an executable file a.out. The last encountered resource is taken as the main resource.

Compilation and linking takes place in the context of an Interfaces directory used for passing specification and object files between sr and srl runs. Files are created in the Interfaces directory as each resource or global is compiled. The Interfaces directory is needed for compilation and linking, but not execution, and can be deleted after an executable has been produced.

Each source file is read twice. The first pass copies component specifications into the Interfaces directory; the second pass generates object code. If errors are detected in the first pass, the second pass is omitted.

Files not ending in .sr (such as .o, .a, and -lxx files) are not processed by sr but are passed along to srl.

OPTIONS

Any of the options s, b, c, M, or C inhibits linking.

-I dir
    Use dir/Interfaces as the Interfaces directory instead of ./Interfaces.

-o file
    Use file for the executable instead of a.out.

-s  Create specification files only (first pass only).

-b  Compile bodies only (second pass only), leaving specification files unaltered.

-c  Compile specs and bodies, but do not link .o files to create an executable file.

-q  Suppress the echoing of source file names as they are compiled.

-w  Suppress warning messages.

-O  Omit some runtime error checks and invoke the C optimizer to improve the generated code.

-T  Omit the ``timeslicing'' code that allows context switching at the top of each loop.

-M  Generate dependency information for use by srm(1), then exit without compiling anything.

Additional options are useful mainly when debugging the compiler:

-C  Stop after generating .c files, leaving them undeleted.

-F  Inhibit constant folding. This can break programs by rendering certain expressions non-constant.

-P  Inhibit normal optimizations in the SR compiler.

-d flags
    Write debugging output selected by flags on standard output.

-e  Use experimental versions of srl and .h files, and pass -e to srl.

-g  Compile for debugging with dbx(1), don't delete .c files, and pass -g to srl.

-v  Announce version number, trace other programs invoked by sr, and pass -v to srl.

ENVIRONMENT

SR_PATH
    When compiling an import statement, sr searches for a corresponding .spec file by looking first in the current directory, then in the Interfaces directory, and finally in the SR library. If SR_PATH is set, any directories named there are checked ahead of the standard search sequence. Directories in SR_PATH are separated by colons (:).

EXECUTION ENVIRONMENT

These environment variables can be set at execution time to affect the behavior of an SR program:

SR_PARALLEL
    Controls the number of processes that can run with true concurrency (as opposed to simulated concurrency) under MultiSR. MultiSR is a configuration option available on the SGI Iris, Sun Sparc running Solaris 2.x, and Sequent Symmetry. The default value is 1 (no true concurrency). It makes little sense to set SR_PARALLEL greater than the number of available processors.

SR_SPIN_COUNT
    In MultiSR, the number of times an idle processor will check for a task before relinquishing the CPU to the operating system. Larger values increase the opportunity for processes to quickly resynchronize at the expense of greater CPU usage. The default is 35.

SR_NAP_INTERVAL
    In MultiSR, the number of milliseconds an idle processor will nap after trying unsuccessfully to find something to run. The default is 10.

SR_TRACE
    If not null, SR_TRACE specifies the name of a file to receive a trace of messages, invocations, and other language-level events. Two special names, stdout and stderr, direct the trace output to standard output and standard error output respectively. The default is no tracing. Traces from remote virtual machines appear only if the trace is directed to stdout or stderr. The srprof(1) program can be used to summarize the trace output.

SR_DEBUG
    A hexadecimal number specifying a bit mask that enables debugging information of various internal runtime events on standard error output. Each bit selects a different message category, and the higher order bits (FFFFFF00) produce the most voluminous output. Details are contained in the source code of the runtime system. The default is no debugging. In contrast with SR_TRACE, the output from SR_DEBUG records internal events of interest to maintainers of the runtime system.

SRXPATH
    Path to the executable of srx, which serves as the central controller of a distributed SR program. The default is configured when the SR system is built.

SRMAP
    File to read for the network configuration information used to generate a host-independent ``network path'' of the executable for executing part of an SR program on a remote host. The default is configured when the SR system is built.

FILES
file.sr    SR source file
a.out    executable program
Interfaces/component.c    C language intermediate file
Interfaces/component.spec    specification file
Interfaces/global.impl    implementation characteristics of global
Interfaces/component.o    object file

SEE ALSO
Gregory R. Andrews and Ronald A. Olsson, The SR Programming Language: Concurrency in Practice. Benjamin/Cummings, 1993, ISBN 0-8053-0088-0.

Gregory R. Andrews, Concurrent Programming: Principles and Practice. Benjamin/Cummings, 1991, ISBN 0-8053-0086-4.

Ronald A. Olsson, Gregory R. Andrews, Michael H. Coffin, and Gregg M. Townsend, SR: A Language for Parallel and Distributed Programming. TR 92-09, Dept. of Computer Science, The University of Arizona, 1992. Included in the SR distribution.

Gregory R. Andrews, Ronald A. Olsson, et al., An Overview of the SR Language and Implementation. ACM Trans. on Prog. Lang. and Systems 10, 1 (January, 1988), 51-86.

srl(1), srm(1), srprof(1), cc(1), dbx(1), srmap(5), srtrace(5)

DIAGNOSTICS

Messages diagnosing erroneous programs are intended to be self-explanatory.

Messages indicating ``compiler malfunction'', or any error messages generated by the C compiler, indicate bugs in the SR compiler that should be reported to its implementors.