Complexity Analysis of A Cache Controller
for Speculative Multithreading Chip Multiprocessors
Yoshimitsu Yanagawa, † Luong Dinh Hung, †† Chitaka Iwama , ††Niko Demus Barli,†† Shuichi Sakai†† and Hidehiko Tanaka††
Although many performance studies of memory speculation mechanisms in speculative multithreading chip multiprocessors have been reported, it is still questionable whether the mechanisms
are complexity eﬀective and worth to implement. In this paper, we perform a complexity analysis
of a cache controller designed by extending an MSI controller to support thread-level memory
speculation. We model and estimate the delay of logic on critical paths and additional area overhead to hold additional control bits in cache directory. Our analysis shows that for many protocol
operations, area overhead occupies more than half of the total delay. This area overhead is however
smaller than the delay for accessing and comparing cache tags. When the protocol operations are
performed in parallel with tag comparison, the critical path latency is increased by 11%. Overall,our results show the cache controller can be implemented with cycle time of less than 22 [FO4],
and can be made faster if we further pipeline the protocol operations.

1. Introduction
Chip Multiprocessor (CMP) architecture is becoming increasingly attractive because of its capability to
exploit Thread Level Parallelism (TLP) in multithreador multiprogram workloads. However, to be fully accepted as a general purpose platform, it must alsodeliver high performance when executing sequential
applications. In order to extract TLP from sequential applications, a technique called speculative multithreading has been proposed [4–6,8,9,11]. In speculative multithreading execution, a sequential program ispartitioned into threads and speculatively executed inparallel. The threads may exhibit data or control dependencies depending on the thread execution model.
Additional hardware and software supports are needed
to recover the execution when the speculation failed.
Speculative multithreading architectures usually use
a combination of control and data speculation to exploit TLP. One of useful speculation techniques isthread-level memory speculation, in which a thread
executes memory load speculatively regardless thepossibility that a predecessor thread may store into
the same memory location. A number of hardware
based mechanisms to support memory speculation
have been proposed. These mechanisms usually extend the functionality of cache to buﬀer speculative
state of memory and detect memory dependency violations [3–5, 9].
Although many performance studies of the memory speculation mechanisms have been reported, it isstill questionable whether the mechanisms are complexity eﬀective and worth to implement. This paper
is an eﬀort to answer this question. In this paper,
we ﬁrst modify MSI (Modiﬁed-Shared-Invalid) cachecoherency protocol to support thread-level memory
speculation. The hardware organization of the cachecontroller necessary to implement the protocol is then† Engineering Department, The University of Tokyo†† Graduate School of Information Science and Technology,
The University of Tokyo1

described and complexity analysis is performed. We
model and estimate the delay of logic on critical paths
and additional area overhead to hold additional control bits in cache directory.
We found that for a 32-kB cache with 64-byte lines,
the increase in area overhead of cache directory over
the original MSI cache directory is signiﬁcant. Access latency to the cache directory is approximately
11.4 [FO4], whereas the logic delay of critical paths
is less than 10 [FO4]. For many protocol operations,area overhead occupies more than half of the total
delay. This area overhead is however smaller thanthe delay for accessing and comparing cache tags.
Since cache directory access and protocol logic operation can be performed in parallel with cache tag
access, signiﬁcant increase in critical path delay can
be avoided. In such a case, our analysis shows thatthe critical path latency is increased by 11%. Overall,our results show the cache controller can be implemented with cycle time of less than 22 [FO4]), andcan be made faster if we further pipeline the protocol
operations.
The rest of this paper is organized as follows. Section 2 describes baseline architecture and memory
speculation model assumed in the paper, and presents
related work. Section 3 explains cache controller support for memory speculation. Complexity of the cachecontroller is evaluated in Section 4. Section 5 concludes the paper.
2. Speculative Multithreading
2.1 Execution Model
Figure 1 depicts an organization of CMP architecture we use in this paper. It consists of four Processing Units (PU) with private register ﬁle, L1 I-Cache,and L1 D-Cache. A uniﬁed L2 cache is shared by all
the PUs. Threads are scheduled to the PUs and their
execution is validated by a Thread Control Unit.
In our speculative multithreading model, a sequential program is partitioned into threads at compile
time. A thread is deﬁned as a connected subgraph of

Thread Control Unit
Processing Unit 0
RegisterSuperscalar Sync. Unit
Core

・・・

PU2

Processing Unit 3
RegisterSuperscalar Sync. Unit
Core

D-CacheController andSpeculation Support
Bus

I-CacheTime
Th1
Load qStore pI-CachePU3

Th0

If p=q,Violation !

D-Cache

PU2
Th0

PU3

Th1
Load qStore p(a) Memory Speculation

Secondary Cache

Re-execute
Th1

SquashthreadController andSpeculation Support

PU3

Load q(ｂ) Thread squash andre-execution

Fig. 1 Baseline architecture

Fig. 2 Memory Speculationa static control ﬂow graph with a single entry point.
Thread boundaries are put at function invocations, innermost loop iterations, and at remaining points necessary to satisfy the thread deﬁnition [1]. Average
thread size is 10-20 dynamic instructions.
At execution time, threads are scheduled to thePUs in a round-robin fashion. The thread model allows control and data dependences to exist between
threads. The Thread Control Unit dynamically predicts threads and validates their execution. Data dependencies through register are synchronized using a
combination of compiler and hardware supports. Finally, memory loads are executed speculatively. In
case a violation occurs, the violating thread and all its
successors are ﬂushed and restarted. The mechanismof memory speculation support is the main subject of
this paper, so we present a more detail explanation in
the next subsection.

tails on how to implement the mechanism on CMP
caches.
Hydra [4] proposed an extension of cache directory
to handle speculative state of the cache line. The
speculation state is managed on per-line basis. A
write-through policy is employed and a speculation
buﬀer is attached to each cache to buﬀer speculatively
stored value.
STAMPede [9] extends the traditional MESI protocol with additional states to support memory speculation. Similar to Hydra, the management of speculative state is performed on per-line basis. However,it diﬀers in that it does not require special buﬀer tohold speculative memory values.
In [5], memory speculation is performed using acentralized table called Memory Disambiguation Table (MDT). MDT is located between the private L1
caches and the shared L2 cache. It records loads andstores executed on L1 caches. Memory management
manages memory state on per-word basis. Since theentry of MDT is limited, memory operation of speculative threads need to be stalled if the table is full.
This work takes a middle course from the latter two
approaches. Rather than using a centralized table, we
extend the MSI protocol to support memory speculation similar to STAMPede. However, we choose to
manage the memory state on per word basis as in[5]. It is because previous work has shown that maintaining the state on a per-line basis results in poor
performance [5].

2.2 Memory Speculation
Figure 2(a) shows an example of memory speculation. Two threads Th0 and Th1 are executed concurrently in the PU 2 and PU 3. The speculation levelof Th1 is higher than Th0. Without memory speculation, the load instruction in Th1 must be delayed
until the execution of the store in Th0 to prevent possible memory RAW violation. In order to avoid suchsynchronization overhead, memory speculation allows
Th1 to execute the load before the store in Th0 is
executed. If the target addresses of these instructions
turn out to be diﬀerent, the speculation succeeds (ﬁgure 2(a)). Otherwise, Th1 as well as all its successor
threads must be ﬂushed and reexecuted (ﬁgure 2(b)).
In order to support the thread-level memory speculation, the underlying architecture must provide amechanism to detect memory dependency violations
and recover the execution. It must also provide abuﬀering mechanism for speculatively stored data. In
this paper, we modify an MSI consistency protocol
and design a cache controller for the purpose. A moredetail description will be given in section 3.
2.3 Related Work
Many models and hardware/software supports forthread level memory speculation have been proposed [2–5, 9, 11]. Among them, [4, 5, 9] provide de2

3. Cache Controller Support for Memory Speculation
3.1 Organization
We integrated a hardware mechanism into each processing unit’s cache controller to support thread-level
memory speculation. The organization of the controller is shown in ﬁgure 3. The controller mainlycomprises four units: state controller that manages
cache states, cache directory that holds cache statesand speculation history, violation detector that detects memory violation, and data forwarder that controls data forwarding between PUs. The controller
manages the state of memory by snooping memory
events broadcasted on a shared memory bus. This

Thread Control Unit

PU 0Store bits

Notify Violation

Forwarded

Superscalar Core
CompareSpeculation Level

Speculation level
Register

Set/Chk
State

CompareSpeculation Level

Violation Detector
Snoop(Check Store)

Data
SearchData
SearchDesignate
Entry

Rd
Wr
Invalidate

BUS

Cache
Directory

Instruction

Load/StoreData

L1 cache

Data
Forwarder

Load/Store
Data

Data
Forwarding
Snoop

64bit * 8
Data
Address 64bit
PU0
Requester PU1
PU2
PU
PU3
Owner
PU

PU0
PU1
PU2
PU3

Modified

Invalid

Stale

S0

S1

S2

Fig. 4 State bits maintained for each word in the cacheState Controller
Notify Store,
Request Data,
Write/Read L2

Load

8bit
8bit
8bit
8bit

Fig. 3 Cache controller organization.

bus includes a pair of data bus and address bus, anda number of control lines necessary to maintain theconsistency of memory.
3.2 Coherence Protocol
Our coherence protocol allows RAW violations tooccur. On the other hand, it provides support to prevent WAW and WAR violations. Data speculatively
stored by a thread is temporarily held in L1 caches.
The data is allowed to be committed to L2 cache only
after the thread becomes a non-speculative thread,thus preventing WAW violations.
To prevent WAR violations, a forwarding mechanism from a producer thread to a consumer threadis provided. When a speculative load misses in L1
cache, the PU sends a request for the corresponding
cache line on the bus. PUs that are executing predecessor threads probe their L1 cache to see if they havethe requested data. If more than one PU owns thedata, the PU executing the most recent predecessor
thread is chosen to forward the data. If no candidate
is found, the L2 cache will supply the data.
The coherence protocol also provides a RAW violation detection mechanism. All words referred byspeculative loads are recorded in the cache directory.
When a store is executed, its destination address isbroadcasted on the bus. Receiving this address, eachPU that executes a thread with higher speculationlevel checks its corresponding cache entry. Violation
is detected if the PU has previously loaded a value
from the same location. In this case, the cache controller notiﬁes Thread Controller Unit to ﬂush andrestart the execution of the thread.
3.3 State Transition
To implement our cache protocol, we prepare
eight control bits (ﬁgure 4) for each word into thecache directory. The ﬁrst four bits, Modiﬁed, Invalid, Forwarded and Load, are used to identify
the state of the corresponding word. A word canbe in one of the following seven states: Modified
3(M),Shared (S), Modified-Loaded (ML), SharedLoaded (SL), Modified-Forwarded-Loaded (MFL),
Shared-Forwarded-Loaded (SFL) and Invalid (I).
These states are encoded by the four state bits asshown in table 1. Modiﬁed bit indicates that a memory word has been modiﬁed. Invalid bit indicates theword is invalid. Forwarded bit is set when the word
was forwarded from a predecessor thread. When anyof the predecessor threads is ﬂushed, memory words
with the Forwarded bit set are invalidated. It is because the forwarded data may be incorrect due tomisspeculation. Load bit is set when the ﬁrst accessto the memory word is a load, and is used to detect
dependency violations.
Table 1 List of states of a word in the cacheState Forwarded
Load Modiﬁed
Invalid
M
0
0
1
0
S
0
0
0
0
ML
0
1
1
0
SL
0
1
0
0
MFL
1
1
1
0
SFL
1
1
0
0
I
X
X
X
1

In addition to these four bits, a set of Store bits
and a Stale bit are also stored in the cache directory.
Store bits identify which of the PUs have stored to thecorresponding address. Each Store bit corresponds toone of three PUs, other than the PU the memory
word belongs to. Store bits are used to avoid unnecessary violation detections. When a store is executedby another PU, its destination address is broadcasted
on the bus. If the store comes from a predecessor
thread, cache controller checks both the Load bit andthe Store bits. Violation is detected if the Load bit
is set, and if none of Store bits corresponding to PUs
whose speculation level is higher than the one thatbroadcasted the store, is set. Stale bit is set at arrival of message indicating that a successor thread has
stored into the same memory address. We call thismessage Delayed Invalidation message (Dyinv). The
message indicates that the data can no longer be usedby future threads. When a thread commits, all words
with Stale bit set are invalidated.
Figure 5 illustrates state transition possible in ourcache coherence protocol. List of events as an input
to this state diagram is listed in table 2.
4. Complexity Analysis
The complexity of our cache model is analyzed interms of hardware overhead incurred by additional

Load, Dyinv
Load (Sl=0)
Load (Sl=1)

Load, Dyinv SFL

Commit (Stale = 1),
Squash,Invalidation
Commit (Stale = 1),
Squash, Replace,
Invalidation

Load,Store,
Dyinv

I

Commit (Stale = 1),
Squash,Invalidation

MFL

ML

Load, Store,
Dyinv

Store

Commit (Stale = 1),
Squash, Invalidation

M

Load, Store,
Dyinv

Commit(Stale = 0),
Load (Sl=0)
SquashCommit (Stale = 1),
Replace, Invalidation

Commit(Stale = 0)

Commit(Stale = 0)Store

Commit (Stale = 1),
Invalidation

Commit (Stale =0,1),
Squash,Invalidation, Dyinv
Store

SL

Commit(Stale = 0)Store
Commit(Stale = 0)

Commit (Stale = 0),
Squash,Dyinv

Load (Sl = 1)

S

Fig. 5 State Transition Diagram

Input
Load (Sl = 0)
Load (Sl = 1)
Store
Replace
SquashCommit (Stale = 0)
Commit (Stale = 1)
Invalidation
Delayed Invalidation (Dyinv)

From
PU corePU corePU corePU core
TCU
TCU
TCU
Bus
Bus

Table 2 List of cache coherence events
Description
The Load issued by the PU and the predecessor thread does not have the data
The Load issued by the PU and the predecessor thread have the data
The Store issued by the PU
Cache line replacement
The thread is squashed
The thread is commit and the Stale bit is set
The thread is commit and the Stale bit isn’t set
The store information is broadcasted from a predecessor thread
The store information is broadcasted from a successor thread

memory state bits and control logic. To quantify overhead of the state bits, we estimate cache access timeusing CACTI tool [7]. Since, the state bits are kept
in the cache directory, we compare the access time
for the cache directory and for the cache itself, anddiscuss possible impact on cache access latency.
Delay of additional control logic is estimated using
the method of logical eﬀort [10]. Using this method,
the delay incurred by a logic gate is calculated as thesum of parasitic delay p and eﬀort delay f. The eﬀort
delay is further expressed as the product of logicaleﬀort g, which describes how much bigger than an
inverter a gate must be to drive loads as well as theinverter can, and electrical eﬀort h, which is the ratioof output to input capacitance of the gate.
d = f + p = gh + p(1)

Delay along N-stage logic path D is given by the sumof delay through each stage:
D=

N

i=1

fi +

N


pi

(2)

i=1

It is known that D is minimum when eﬀort delay
through each stage is equal to an optimal eﬀort de-4ˆ
lay f:
D̂ = N fˆ +

N


pi

(3)

i=1

where fˆ is given by
N
N
N



fˆ = F 1/N = ( gibihi )1/N
i=1

i=1

(4)

i=1

Here, bi is branch eﬀort of stage i, which estimates
the fanout eﬀect of the logic gate in the stage.
To estimate delay overhead of control logic, we
model critical path of the logic and calculate D̂ along
the path. As a measure of the delay, we use thedelay through an fanout-of-four (FO4) inverter. It
is known that delay normalized by the FO4 metrics
holds constant over a wide range of process technologies. To provide a concrete example, absolute delay
at 90 nm technology will also be shown, assuming
1 [FO4] = 36 ps.
4.1 Cache Directory Access TimeIn this section, we discuss overhead incurred bycache state bits. The L1 cache conﬁguration we as-sume is given in table 3. We assume that cache data,tag, and state bits are each kept in a separate memory structure. Our coherence protocol requires eightstate bits per word. Assuming 32-kB cache with 64byte lines, this results in 4 kB of cache directory intotal. Because additional state bits are required tomaintain speculative state and the states are kept ona per word basis, the directory size is much larger thanthe one for conventional coherence protocol. For example, the simplest MSI protocol only needs threestate bits per line. Then the directory would be only
192 bytes in size.
Table 3 L1 cache parameters
Size
32 kB
Line Size
64 bytes
Associativity
2Tag
21 bits

Violation Detection
On receiving a broadcast that a store has been executed, each PU ﬁrst identiﬁes which PUs have stored
to the corresponding word by checking its store bits.
It then compares speculation level of those PUs with
its own speculation level and with that of the latest
store. Finally it checks modiﬁed bit and load bit of
the word and detects violation.
State Transition
Manage the update of state bits in the cache directory as previously described in ﬁgure 5 and table 2.

Delay [FO4]
13.9
7.3
18.6
21.2

Owner Probing
Data Transfer
Violation Detection
State Transition

Table 4 shows cache access latency estimated using CACTI. It can be seen the cache directory accesslatency is less than tag access latency. In this case,the critical path is in tag access operation. Since thedirectory access can be performed in parallel to tag
access, it is expected that the directory would notaﬀect cache access latency. In this estimation, we assume 32 bit address space. In larger address space,tag array would be larger and require more accesstime, so that cache directory is less likely to come on
the critical path.

Delay @90nm [ps]
500
263
668
763

Table 5 Operation delay including access time to cachedirectory

Table 5 summarizes estimated time needed for each
operation. The operation times include access time toStage 2
g = 7/3
p=3
Cout = kC

Cache Directory

Address 64bit

Hit

Modified

Set Owner PU line
Data
RequestTable 4 Cache access time
Delay (FO4) Delay @90nm [ps]
Data
17.3
622
Tag
19.1
689
Directory
11.4
410

Stage 1g=1
p=1
Cin = CBus

To Bus(Owner PU line)kC

To Bus(Owner PU
line foreach word)

F = 56k/3
f = 4.32 * k
P =4
D = 8.64 * k + 4
1 FO4 Delay = 5
if k = 1,
D = 12.64 / 5= 2.5 FO4
Cache Directory access time= 11.4 FO4Total Delay = 13.9 FO4½½

4.2 Control Logic Delay
We estimate complexity of control logic required for
four main operations of the cache controller: ownerprobing and data transfer for data forwarding between
PU, violation detection and state transition. Criticalpaths of each logic block are illustrated in ﬁgure 6∼ 9, along with their estimated delay. Functions of
those logics are described brieﬂy below.
Forward - Owner Probing
On receiving a forward request, each PU checks if
it has the requested line in the cache. Then it checks
modiﬁed bit for each word in the line, and if the bit
is set, asserts owner PU line to claim its ownership.
Forward - Data Transfer
Each PU examines which PUs have claimed ownership for the requested words. It compares speculationlevel of all the owner PUs, and checks if it is qualiﬁed
to forward the word. If it is, it puts the word on thebus, and if not, send a request to L2 cache.

Check Modified bit
for each word

Fig. 6 Forward - Owner Probing
F = 8918000k / 6561
1/8

f = 2.464 * k
P = 17

1/8

D = 19.712 * k+ 17

1 FO4 Delay = 5Compare the speculation level to check if the
speculation level is highest among the owner PUs
and if the PU is a predecessor of the requester PU

if k = 1,
D = 36.712 / 5
Stage 8= 7.3 FO4

Select the speculation level
correspond to the owner PU

Stage 5

Stage 6

Stage 7

g = 4/3

g = 1

p = 2

p = 1

g = 7/3

p = 2

No data can bep = 3

forwardedTo L2 Cache

Stage 1
g = 1

ENB
ENB
ENB
ENB
ENB
ENB

p = 1
Cin = C
Stage 2

Stage 4

g = 5/3

Stage 3p = 2

g = 7/3

ENB

g = 7/3
p = 3

L1 cache

p = 3

・
・・

Data
64 bitOwner PU linekC
Put data on
the bus if
possible

Data BusBus

Fig. 7 Forward - Data Transfer

5

g = 5/3

Cout = kC

Select Speculation
Level Correspondto Store bit

Compare speculation level if there is apredecessor whose speculation levelis higher than PU that issued store

Check if the PU loaded
the data in the thread

Stage 7g = 5/3
p = 2
Cout = kC

Stage 1

Load bit

g = 1
p = 1

Violation !

Cin = CStore bit
Cache
Directory

Stage 2

Stage 4

Stage 5g = 5/3

g = 5/3

p = 3

p = 3

g = 4/3
p = 2

Stage 3g = 5/3
p = 3

To TCU

Stage 6
g = 2
p = 4

F = 166400k / 243
f = 2.5414 * k
P = 18
D = 17.79 * k + 18
1 FO4 Delay = 5
if k = 1,
D = 35.79 / 5= 7.16 FO4Cache Directory access time = 11.4 FO4Total Delay = 18.6 FO4

kC

1/7

1/7

Fig. 8 Violation Detection

basis rather than per-line basis. For many protocol
operations, area overhead occupied more than halfof the total delay. This area overhead is however
smaller than the delay for accessing and comparing
cache tags. When the protocol operations are performed in parallel with tag comparison, the critical
path latency is increased by 11%. Overall, our results
showed the cache controller can be implemented withcycle time of less than 22 [FO4]. The cycle time canbe made shorter if we further pipeline the protocol
operations, for example by splitting cache directory
access and logic operation. The impact of this optimization to the performance is the future work of thisresearch.
Acknowledgement

Cache
Directory
Load

Stage 2
g=3
p=4

Stage 3g = 5/3
p=3

Stage 4
g = 7/3
p=5

Stage 5
g = 7/3
p=3

Stage 7g = 5/3
p=2

Stage 8g=2
p=6Cout = kC

SelectStage 1g=1
p=1
Cin = C

Stage 6
g = 7/3
p=5

Data In

MUX

To
DirectorykC

F = 3704400k / 2430
f = 2.4997 * k1/8
P = 29D = 19.9976 * k1/8 + 29
1 FO4 Delay = 5
if k = 1,
D = 48.9976 / 5= 9.8 FO4
Cache directory access time = 11.4 FO4
Total Delay =21.2 FO4This research is partially supported by Grant-in-Aid
for Fundamental Scientiﬁc Research B(2) #13480077
from Ministry of Education, Culture, Sports, Scienceand Technology Japan, Semiconductor Technology
Academic Research Center (STARC) Japan, CREST
project of Japan Science and Technology Corporation,and by 21st century COE project of Japan Society for
the Promotion of Science.
References

Fig. 9 State Transition

cache directory, which has been previously estimatedto be 11.4 [FO4] (table 4). It can be seen that directory overhead occupies a large part of path delay.
The results also indicate that the control logic slightly
extend the critical path by 11% from 19.1 [FO4] (tagaccess latency) to 21.2 [FO4] (state transition update). Overall, it is estimated that the cache controller can operate at a reasonable cycle time of lessthan 22 [FO4]. This can be made faster by applying
optimizations such as pipelining the directory accessand logic operation.
5. Conclusion
A number of memory speculation mechanisms in
speculative multithreading chip multiprocessors havebeen proposed and many performance studies havebeen reported. However, it is still doubtful whether
the mechanism is complexity eﬀective to implement.
In this paper, we performed a complexity analysis ofa cache controller designed by extending an MSI controller to support thread-level memory speculation.
We modeled and estimated the delay of logic on critical paths and area overhead to hold additional control
bits in cache directory.
We found that the increase in area of cache directory over the original MSI cache directory is signiﬁcant. This is a consequence of the requirements tomaintain speculative state of memory on a per-word

6[1] N. D. Barli, H. Mine, S. Sakai, and H. Tanaka. A Thread
Partitioning Algorithm using Structural Analysis. ARC2000-139, 2000(24):37–42, 2000.
[2] M. Franklin and G. S. Sohi. ARB: A Hardware Mechanism for Dynamic Reordering of Memory References. IEEE
Transactions on Computers, 45(5):552–557, 1996.
[3] S. Gopal, T. N. Vijaykumar, J. E. Smith, and G. S. Sohi.
Speculative Versioning Cache. In Proc. of the 4th International Symposium on High-Performance Computer Architecture, pages 195–205, 1998.
[4] L. Hammond, M. Willey, and K. Olukotun. Data Speculation Support for a Chip Multiprocessor. In Proc. of the
8th International Symposium on Architectural Support for
Parallel Languages and Operating Systems, pages 58–69,
1998.
[5] V. Krishnan and J. Torrellas. A Chip-Multiprocessor Architecture with Speculative Multithreading. IEEE Transactions on Computers, 48(9):866–880, 1999.
[6] P. Marcuello, A. Gonzalez, and J. Tubella. Speculative
Multithreaded Processors. In Proc. of the 12th International Conference on Supercomputing, pages 77–84, 1998.
[7] P. Shivakumar and N. P. Jouppi. CACTI 3.0: An Integrated Cache Timing, Power, and Area Model. Technical
Report WRL-2001-2 HP Labs Technical Reports, 2001.
[8] G.S. Sohi, S.E. Breach, and T.N. Vijaykumar. Multiscalar
Processors. In Proc. of the 22nd International Symposiumon Computer Architecture, pages 414–425, 1995.
[9] J. G. Steﬀan, C. B. Colohan, A. Zhai, and T. C. Mowry. A
Scalable Approach to Thread-Level Speculation. In Proc.
of the 27th International Symposium on Computer Architecture, pages 1–12, 2000.
[10] I. E. Sutherland, R. F. Sproull, and D. Harris. LogicalEﬀort: Designing Fast Cmos Circuits. Morgan Kaufmann,
1999.
[11] J.-Y. Tsai, J. Huang, C. Amlo, D. J. Lilja, and P.-C.
Yew. A Chip-Multiprocessor Architecture with Speculative Multithreading. IEEE Transactions on Computers,
48(9):881–902, 1999.