2 The SPARC Architecture Manual: Version 8
1.2. SPARC System
Components
The architecture allows for a spectrum of input/output (I/O), memory manage-
ment unit (MMU), and cache system sub-architectures. SPARC assumes that
these elements are optimally defined by the specific requirements of particular
systems. Note that they are invisible to nearly all user application programs and
the interfaces to them can be limited to localized modules in an associated
operating system.
Reference MMU The SPARC ISA does not mandate that a single MMU design be used for all sys-
tem implementations. Rather, designers are free to use the MMU that is most
appropriate for their application — or no MMU at all, if they wish. A SPARC
“Reference MMU” has been specified, which is appropriate for a wide range of
applications. See Appendix H, “SPARC Reference MMU Architecture,” for
more information.
Supervisor Software SPARC does not assume all implementations must execute identical supervisor
software. Thus, certain supervisor-visible traits of an implementation can be
tailored to the requirements of the system. For example, SPARC allows for
implementations with different instruction concurrency and different exception
trap hardware.
Memory Model
A standard memory model called Total Store Ordering (TSO) is defined for
SPARC. The model applies both to uniprocessors and to shared-memory mul-
tiprocessors. The memory model guarantees that the stores, FLUSHes, and
atomic load-stores of all processors are executed by memory serially in an order
that conforms to the order in which the instructions were issued by processors.
All SPARC implementations must support TSO.
An additional model called Partial Store Ordering (PSO) is defined, which allows
higher-performance memory systems to be built.
Machines (including all early SPARC-based systems) that implement Strong
Consistency (also known as Strong Ordering) automatically satisfy both TSO and
PSO. Machines that implement TSO automatically satisfy PSO.
1.3. SPARC Compliance
Definitions
An important SPARC International Compatibility and Compliance Committee
function is to establish and publish SPARC Compliance Definitions (SCDs) and
migration guidelines between successive definitions. SCD use accelerates
development of binary-compatible SPARC/UNIX systems and software for both
system vendors and ISV members. SPARC binaries executed in user mode
should behave identically on all SPARC systems when those systems are running
an operating system known to provide a standard execution environment.
AT&T and SPARC International have developed a standard Application Binary
Interface (ABI) for the development of SPARC application code. Software con-
forming to this specification will produce the same results on every SPARC
ABI-compliant system, enabling the distribution of ‘‘shrink-wrapped’’ SPARC
software. Although different SPARC systems will execute programs at different
rates, they will generate the same results.
SPARC International, Inc.
