Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!portal!cup.portal.com!mslater
From: mslater@cup.portal.com (Michael Z Slater)
Newsgroups: comp.arch
Subject: Re: New SPARC definition
Message-ID: <40492@cup.portal.com>
Date: 23 Mar 91 19:01:30 GMT
References: <1991Mar21.185847.27784@elroy.jpl.nasa.gov>
Organization: The Portal System (TM)
Lines: 49




>I have heard a couple blurbs about Sparc International releasing a
>new version of the SPARC architecture.  Does anyone have any concrete
>details on what things have changed from the original SPARC definition?
>I assume that it will be upwardly compatible.  I have also heard bits
>about it being better suited for multiprocessing.  Maybe a integer
>multiply and divide?

>Or is it just another person confusing a new implementation with a
>new architecture?

Version 8 of the spec is indeed an updated architecture definition, not just
a new implementation. In fact, there are no announced implementations of
version 8.

The version 8 specification adds integer multiply and divide instructions. 
In addition, a "Store Barrier" instruction was added that requires all stores 
initiated before it to be completed before operation can continue. This is 
designed to support future multiprocessor machines that allow memory 
operations to occur out-of-order.

Version 8 formally specifies a no-op instruction. This does not add a new 
opcode but is just a recommendation for which of the many possible "no 
operation" instructions (such as moving any register to register 0) 
compilers should use. This will be helpful for future superscalar 
implementations, since it makes it easier to identify instructions as no-ops 
that can be discarded. The new specification also redefines the existing 
80-bit floating-point instructions to be 128-bit quad precision.

The forthcoming Lightning, Pinnacle, and Viking processors presumably 
will include the version 8 extensions. Existing SPARC processors trap on 
any undefined instructions, and Sun's current operating system already 
emulates the new multiply and divide instructions in the trap handler. The 
Store Barrier instruction is simply a no-op in existing systems, which don't 
perform out-of-order stores. Programs using the new instructions are 
therefore fully compatible with existing hardware, as long as 
quad-precision floating-point is not used or emulation is provided.

The new document also includes the reference MMU specification and 
recommended ASI (address space identifier) assignments. Many changes 
have been made to the wording to eliminate ambiguities and ensure 
compatibility among various implementations. The specification also adds a 
precise memory model, specifying a set of rules for out-of-order memory 
transactions, which Sun claims is important to provide portability for 
multiprocessor applications.

Michael Slater, Microprocessor Report   mslater@cup.portal.com