Why is TSO ?

> [OpenSPARC] T1 supports TSO memory model.

> TSO allows later loads to bypass earlier stores.

Yes, these statements are true.

> But T1 is a single-issued processor; later loads can't bypass earlier stores.

> I think T1 is a nature Sequential Consistency processor other than a TSO processor.

No, neither of these statements are true.

The memory model(s) a processor implements (Sequential Consistency, TSO, RMO, etc) are independent of how many instructions it can issue per cycle.

Just because UltraSPARC T1 is a single-issue processor, one cannot assume that its memory operations are Sequentially Consistent.

Implemented memory models are also independent of the number of physical processor chips that may reside in the system. The existence of other microarchitectural features, such as store buffers, influence what memory models are implemented, even in single-processor-chip systems.

In fact, OpenSPARC T1 does not implement Sequential Consistency. It implements TSO for almost all operations. The only exceptions are block load and block store operations, which operate under the less-restrictive RMO memory model (regardless of the memory model chosen by the PSTATE.mm control field).

dweaver at 2007-7-6 22:39:35 >

> I seem to know a little. Since memory model is

> independent of issue-width and the number of

> processors, the TSO, PSO and RMO may be implemented

> in the uniprocessor system.

Note, however, that in uniprocessor systems or single-threaded

applications, these weak memory models will appear to software

as though they were Sequential Consistency.

> I still have several problems. How to implement a TSO

> or any other weaker memory model? I eagerly know how

> to implement a memory model, for instance, in T1.

For example, the presence of store buffers (which allow subsequent

loads to perform before or concurrently with the buffered stores)

gives performance boost but it breaks Sequential Consistency, as

pointed out in David's reply.

> For example, following is a code slice. A and B are

> memory addresses.

> 1)Store A

> 2)Load A

> 3)Store B

> This same code slice is executed simultaneously by

> two processors in the T1. When Store A in processor

> P1 and Store A in the processor P2 take place

> concurrently, How can two processors know the memory

> operations order (the order of the two store A )?

This example is a "data race" where one of the two stores will

reach the memory subsystem first. The race resolution is arbitrary.

However, cache coherence guarantees that any processor

(strand) trying to observe location A will see the effect of the two

stores in the same order.

>

> At the same time, the cache coherence is guaranteed

> by memory model (?), and the UltraSPARC architecture

> 2005 has introduced the synchronization mechanism

> addition with cache coherence and memory model. I

> want to know the relationship among cache coherence,

> synchronization mechanism and memory model.

Generally speaking, cache coherence is only a per-location

guarantee (stores to each location may be observed in an

arbitrary order but all processors will observe their effect in the

same order), while a memory model explains the behavior over

the entire memory space across all locations.

Under TSO memory model, a load can bypass its preceding stores.

When this feature is undesirable (e.g., making it too difficult to write

correct code), a "MEMBAR #StoreLoad" instruction can be used

to prevent such reordering at that point, i.e., no loads can bypass

any stores preceding the MEMBAR.

cmanovit at 2007-7-6 22:39:35 >

The order in which instructions update the processor state (registers/condition codes) has little to do with the order in which instructions access memory. It is the former ordering that is required for precise traps (precise interrupts in Hennessy and Patterson).

Clearly, before a load can retire it must have accessed memory, but for the purposes of precise trapping, it could have accessed memory before an older memory-accessing instruction.

A store can be committed to memory after the store has retired. Typically, for normal memory locations, no trap is possible because the memory location is guaranteed to exist. Stores to I/O locations can still meet trap conditions, but such traps are not precise.

PaulL

PaulL at 2007-7-6 22:39:35 >

MEMBAR #Sync provides a barrier such that any instructions issued

after the membar, only execute after any exceptions due to earlier

instructions are visible in the cpu's program state.

the "traps" and "registers" section in the sparc v9 manual has a

*very* detailed description of what program state is.

ssgam at 2007-7-6 22:39:35 >

> the "traps" and "registers" sections in the sparc v9 manual have

> *very* detailed descriptions of what program state is.

I would just modify this to recommend that, instead of the 1994 SPARC V9 book, you instead consult the current UltraSPARC Architecture specification (available from http://opensparc-t1.sunsource.net/). It provides much more up to date and comprehensive "program state" information (esp with respect to OpenSPARC T1) than the SPARC V9 book.

dweaver at 2007-7-6 22:39:35 >