STRAIGHT: Hazardless Processor Architecture
Without Register Renaming
Hidetsugu Irie, Toru Koizumi, Akifumi Fukuda, Seiya Akaki, Satoshi Nakae, Yutaro Bessho, Ryota Shioya
The University of Tokyo
Tokyo, Japan
irie, koizumi, a.fukuda, akaki, nakae, bessho@mtl.t.u-tokyo.ac.jp, shioya@ci.i.u-tokyo.ac.jp

Takahiro Notsu, Katsuhiro Yoda, Teruo Ishihara

Shuichi Sakai

FUJITSU LABORATORIES LTD.
Kawasaki, Japannotsu.takahiro, yoda.katsuhiro, ishihara@jp.fujitsu.com

The University of Tokyo
Tokyo, Japansakai@mtl.t.u-tokyo.ac.jp

Abstract—The single-thread performance of a processor improves the capability of the entire system by reducing the critical
path latency of programs. Typically, conventional superscalar
processors improve this performance by introducing out-oforder (OoO) execution with register renaming. However, it isalso known to increase the complexity and affect the power
efficiency. This paper realizes a novel computer architecture
called “STRAIGHT” to resolve this dilemma. The key feature
is a unique instruction format in which the source operandis given based on the distance from the producer instruction.
By leveraging this format, register renaming is completely
removed from the pipeline. This paper presents the practical
Instruction Set Architecture (ISA) design, the novel efficient
OoO microarchitecture, and the compilation algorithm for the
STRAIGHT machine code. Because the ISA has sequential
execution semantics, as in general CPUs, and is provided witha compiler, programming for the architecture is as easy asthat of conventional CPUs. A compiler, an assembler, a linker,
and a cycle-accurate simulator are developed to measure theperformance. Moreover, an RTL description of STRAIGHT isdeveloped to estimate the power reduction. The evaluation using
standard benchmarks shows that the performance of STRAIGHT
is 18.8% better than the conventional superscalar processor of thesame issue-width and instruction window size. This improvement
is achieved by STRAIGHT’s rapid miss-recovery. Compilation
technology for resolving the possible overhead of the ISA is also
revealed. The RTL power analysis shows that the architecture
reduces the power consumption by removing the power forrenaming. The revealed performance and efficiencies support thatSTRAIGHT is a novel viable alternative for designing general
purpose OoO processors.
Index Terms—microprocessor, instruction-level-parallelism,
out-of-order execution, register renaming, computer architecture,compiler, power efficiency

I. I NTRODUCTION
In response to the trends in semiconductor technology,
processor architecture has been continually evolving to achieve
This research was partially supported by JSPS KAKENHI Grant Number
25730028, and 16H05855. Also, this research was partially supported by
VLSI Design and Education Center(VDEC), The University of Tokyo with thecollaboration with Synopsys Corporation and Mentor Graphics Corporation.

higher performance, more functions, and higher power efficiency. Currently, for the wide range of purpose from embedded processors to server processors, the heterogeneous multicore architecture [1] is adopted, which typically implements
various types and various scales of cores into a chip; the mostefficient cores among them are in charge for each application
depending on its characteristics. This strategy trades off energy
efficiency against lower-utilized cores, reflecting the recent
dilemma that even though the number of transistors can beincreased, they cannot be switched simultaneously [2]. In
this scenario, the CPU is expected to effectively execute theprograms that are not parallelized or cannot be parallelized
by the programmer. Because they are often critical paths that
require the longest execution time among the ongoing tasks,
speeding up a single-thread execution is essential to improve
the total system performance.
Currently, a big superscalar core is inevitably accepted
as the most powerful and the only feasible architecture togain this performance. Provided with an out-of-order (OoO)
mechanism and a number of predictors, the sophisticatedsuperscalar core can exploit the underlying instruction-level
parallelism (ILP) in a thread relatively well. However, a further
increase in its performance is challenging because the powerof indirect operation increases with the scale of the core, whichis critical in today’s limited power budgets. Therefore, therecent improvement in single-thread performance is relatively
modest compared to those of GPUs and TLP technologies,
which demonstrate a performance increase that is proportional
to the increase in the number of transistors employed [3] [4].
This paper realizes a novel OoO execution architecture that
reduces the amount of indirect operations per instruction. The
key idea is that the unique instruction set architecture (ISA)
is adopted to skip register renaming. The ISA guarantees
that each logical register will be written only once and thendiscarded in a fixed period. As the paper elaborates later,
this rule renders register renaming unnecessary, thus resulting
in a simple OoO execution structure as well as a scalable
instruction window for exploiting much larger ILP with simple

hardware. The architecture is called “STRAIGHT” because
it executes each instruction directly without renaming its
operands. The architecture actually requires the ISA to bechanged; however, the code is easily translated from the staticsingle-assignment (SSA) form [5] [6] intermediate language,
which is recently dominant for compiler infrastructures suchthat the viability is not compromised.
A cycle-accurate simulation environment and a registertransfer level (RTL) description of STRAIGHT are developed
to the evaluation. Also, those environment of OoO RISC-V
are developed as a superscalar counterpart. The evaluation
result demonstrates that STRAIGHT improves the singlethread performance and reduces the power consumption, bothof which are derived from the simpler hardware organizationthat is enabled by the ISA.
The concept of the ISA to eliminate register renamingis presented herein [7]; however, the method to realize themicroarchitecture and the compiler of the architecture that can
execute any kind of general-purpose programs has not been
revealed. By presenting the essential hardware and software
technologies, the contribution of this paper are as follows:
The practical STRAIGHT ISA is built to write application
programs. The ISA feature is that the source operands are
given by the distance from the producer instruction.
• The microarchitecture that receives STRAIGHT ISA isrealized. We show that this approach completely removes
register renaming from the OoO core. This means thatthe major hotspots and critical paths are eliminated fromthe front-end pipeline. Furthermore, the simplified architecture achieves the rapid miss-recovery as well as thefurther reorder buffer (ROB) scalability.
• The compilation algorithm that generates STRAIGHT
machine code from the LLVM [8] intermediate representation (IR) is developed. Padding with simple registermove (RMOV) instructions, we show that most operands
can be converted to the statically determined distances
and the remainder can also be represented using the
SPADD instruction.
• A cycle-accurate simulator that faithfully models thepipeline stages of STRAIGHT is developed for the
performance evaluation. The compiled code of standard
benchmarks (Dhrystone, Coremark) is used. The resultshows that STRAIGHT achieves 18.8% better performance than modern OoO superscalar processors while
requiring a simpler hardware. STRAIGHT’s lower misspenalty enhances the performance. The restriction of
STRAIGHT ISA can deteriorate the performance withincreasing redundant RMOV instructions; however, mostof them are eliminated algorithmically by the compiler.
• The power efficiency is confirmed through RTL power
analysis. In-house RTL descriptions of STRAIGHT
is prepared. Comparative evaluation reveals thatSTRAIGHT removes the power of register renaming andimproves the entire efficiency of the processor.

•

The remainder of this paper is organized as follows: Section

II describes the motivation and the basic concept of the
STRAIGHT architecture. Section III presents the details ofboth the ISA and the microarchitecture. Section IV presents
the compiler algorithm to generate the STRAIGHT machinecode. Section V shows the evaluation settings, followed bysection VI, which presents the evaluation results. Section VII
discusses the related works, and the paper is concluded in
section VIII.
II. M OTIVATION
A. Advantages and Disadvantages of Register Renaming
To enhance the single-thread performance, register renamingis critical in exploiting the additional ILP by solving the false
dependency hazard dynamically. In the front-end pipeline,
register renaming is applied to every instruction. It converts all
operand identifiers from logical register numbers to physicalregister numbers that indicate the addresses in the internalregister file. This operation is implemented by multiple references to the table composed of RAM or CAM that is called
the register mapping table (RMT) or the register alias table(RAT).
In the RAM-based RMT, which has as many rows as thenumber of logical registers, the RMT stores the corresponding
physical register number using the logical register number as
an index. The mechanism also has a circular FIFO called freelist that holds all the physical register numbers that do notcorrespond to any logical register at that time. The operationfor each instruction is as follows: i) The RMT is accessedwith source register numbers, and source physical register
numbers are obtained. The RMT is accessed simultaneouslywith the destination register number, and the previous dedicated physical register number is obtained for the recovery
and retire operation. ii) A physical register number is provided
from the head of the free-list, and sent to the next pipeline
stage as the destination physical register number. The RMT
is simultaneously updated by writing this physical register
number. Through these operations, the code is now able toexploit much greater parallelism.
However, register renaming is reported to be one of thehotspots in terms of both power density and power consumption [9] [10] [11] [12]. It lowers the efficiency of the OoO
CPU cores, with the result that a large fraction of energy
is consumed by RMT accesses that are not essential for the
execution. Each instruction requires three reads and one writein a cycle, and the required number of read/write ports is
multiplied by the number of fetch width, which renders the
RMT one of the most multiported tables in the processor. This
multiported access also affects the clock frequency because
unless the RMT updates are completed, the renaming of thenext fetch group cannot start [13].
Moreover, the scalability of the instruction window whose
size determines the amount of exploitable ILP is also disturbed
by register renaming. The instruction window size is directly
related to the ROB, in which all in-flight instructions fromthe dispatch stage to the retire stage are queued. However, thesize of ROB proportionally increases the branch miss-penalty.

When a mispredicted branch instruction is detected, the RMTmust be restored by walking the ROB from the tail (or from thehead, depending on the implementation) to the corresponding
branch instruction. The penalty is reported as several tens ofcycles with the 256-entry ROB on average, which considerably
affects the performance [14].
To be exact, a CAM-based RMT can avoid this penalty atthe expense of a large amount of RMT checkpoints. However,it still disturbs the ROB scalability because the CAM-based
RMT cannot increase the number of physical registers. If thenumber of physical registers are not sufficient for the number
of ROB entries, the stall due to the shortage of free physicalregisters increases. Although register renaming provides animportant contribution to the acceleration of single-thread
execution, it also introduces design limitations, that causes theslow progress in core performance improvement.
B. STRAIGHT Architecture Concept
Instead of managing the physical registers dynamically,
the STRAIGHT concept has been presented to solve thefalse dependency hazard by the compiler, which eliminates
register overwrites [7]. Because the number of registers is
finite, each register is freed after a fixed period such that the
program length is not limited. To write the looped code without
overwrites, a technique is introduced. Register numbers areindicated relatively by the dynamic instruction distance. In thearchitecture, fetched instructions can be directly dispatched tothe scheduler. Not managed by any mapping table, the register
file can be built as a simple key-value store that is easy to scale.
However, realizing the computer for this novel instruction
format involves a number of challenges. Because of the uniqueoperand format, the practical ISA that can write the real application has to be newly constructed. Especially, its viability
significantly owes to the code generation, nevertheless, todevelop the compiler for this instruction format is a novel
challenge. Moreover, in previous STRAIGHT concept, thescalability has been prioritized and the large hardware thatis provided with thousands of registers are assumed, which
limits its use to the desktop or sever processors.
Hereafter in this paper, we realize and evaluate STRAIGHT
processor by resolving the challenges above. Also We design
STRAIGHT microarchitecture as small as conventional mobile
processors, which increases the opportunities to be utilized.
III. E FFICIENT STRAIGHT P ROCESSOR C ORE
A. Specifying STRAIGHT ISA
The developed STRAIGHT instruction set is a collectionof simple operations similar to the typical RISC architectures.
As in conventional OoO superscalar architectures, it provides
a sequential execution model and precise interrupts to theprogrammer.
Figure 1(a) shows a simple example of the STRAIGHT
code. Each instruction performs an ordinary operation, but its
operands are given by the distance from the instruction that
produces the source value. For example, “[1]” of instruction/Ϭ͗KZ/ΨZKϭηϭ/ϭ͗KZ/ΨZKϭηϭ/Ϯ͗΀ϭ΁΀Ϯ΁ ηϮ/ϯ͗΀ϭ΁΀Ϯ΁ ηϯ/ϰ͗΀ϭ΁΀Ϯ΁ ηϱ/ϱ͗΀ϭ΁΀Ϯ΁ηϴ/ϲ͗΀ϭ΁΀Ϯ΁ ηϭϯ(a)ĞƌŽZĞŐdǇƉĞ
ϯϭϮϱ
KWK

Ϭ/ŵŵKŶĞZĞŐdǇƉĞ
ϯϭϮϱ
KWK
ƐƌĐZĞŐ

ϭϱdǁŽZĞŐdǇƉĞ
ϯϭϮϱ
KWK
ƐƌĐZĞŐ>ϭϱϬ/ŵŵƐƌĐZĞŐZ

ϱ
Ϭ
;/ŵŵͿ

(b)

Fig. 1. Example of STRAIGHT code and bit-field formats

I2 means that the instruction uses the result value of the previous instruction, and “[2]” means that the other operand is theresult value of the second previous instruction. Therefore, thiscode calculates a Fibonacci series as long as the “ADD [1][2]” instruction is repeated. It is noteworthy that an operandis represented as the distance in a control flow. Therefore,
it differs from the distance in the static order when a code
contains nonsequential program counter (PC) transitions suchas jump instructions.
Based on the above concept, we defined the bit-field format of the STRAIGHT instruction set architecture as shownin figure 1(b). Because an instruction does not specify thedestination register identifier, each identifier for the source
operands can use a larger field. A source operand field canspan up to 10 bits, which means that the results of the last
210 − 1 = 1023 instructions can be referenced. Here, “[0]”is decoded as a zero register. Store (ST) instructions need not
make the register output, but to make the distance calculation
simple, each instruction occupies one destination register. If it
is referred, store value is returned in the current specification.
This unique representation contains some characteristicsof the dataflow, and satisfies the following restrictions corresponding to the STRAIGHT concept. First, it guarantees
the write-once usage of each register. A register is identified
by the fetch order of the instruction, with the result thatany two instructions never share the same destination. Next,
because the operand is identified by the distance in the control
flow path, the lifetime of each register is determined by the
maximum distance (e.g., 1023 instructions). The value will
be never referenced after the succeeding 1023 instructions are
executed.
STRAIGHT requires an additional architectural register,“stack pointer (SP).” This is the only overwritable register, andit guarantees that any complicated algorithm can be written at
the least using SP as a memory pointer. We find that adding
one instruction, “SPADD” to the instruction set is sufficient
to SP-related operations, which reads and modifies the SP
by adding the given immediate value as well as writing thisresult to its destination register. The succeeding load andstore instructions can use the SP value by indicating the
distance from the SPADD instruction. As described in thecompiler section below, the SPADD is utilized to compile thecomplicated control flows such as function calls.

ŝƐZĞĐŽǀĞƌǇ

Reorder Buffer

BranchPrediction^W

Register
file
RF
ALU

ZW

Instruction
Cache

Ͳ

ŝŶƐƚ͘ϭ

Store
Unit

SP/RP
Processing

Load
Unit

Ͳ
ŝŵŵ Ϭ

ALU

Issue
Queue

ĨƌŽŶƚĞŶĚ
ǁŝĚƚŚ

ϭ

н

ĨĞƚĐŚ

ZK

η^ZͲ>
η^ZͲZ
η^d
η^W

ZK

^ĐŚĞĚƵůĞƌ

нĚŝƐƚĂŶĐĞ

Data
Cache

Schedulerη^ZͲ>
η^ZͲZη^dη^WŝƐ^W

ͲŝŶƐƚ͘Ŷ

L2/L3
MemoryZĞĐŽǀĞƌǇ ZWĚŝƐƚĂŶĐĞ

ĨĞƚĐŚ

Decoder

FetcherZĞĐŽǀĞƌǇ ^W

Ͳ
ŝŵŵ Ϭ
ϭ

^ĐŚĞĚƵůĞƌ

ŝƐ^W

н

L2/L3
MemoryFetch

Dispatch
DecodeSchedule

Issue
Execution
RetireRegister
Register
Write
Read

н

Fig. 3. The mechanism of operand determination in the front-end pipelineĚŝƐƉĂƚĐŚ
^WdĂďůĞ

ZKdĂŝůFig. 2. Pipeline organization of STRAIGHT^WW

B. Realizing Scalable OoO Execution
The pipeline organization of STRAIGHT is designed asshown in figure 2. As the operations of the instruction set
are similar to those of conventional RISC architectures, mostof the pipelines are also composed of conventional mechanisms. The major differences are in the following mechanisms:
the mechanism in the front-end pipeline that determines theoperand register number and the retire/recovery mechanism,
which is related to the ROB.
First, the detailed mechanism of the operand determinationis shown in figure 3. This operation corresponds to the RMTaccesses for conventional OoO superscalar processors. To
obtain the physical source register numbers from the source
distances given by an instruction, a special register, register
pointer (RP), is introduced in the hardware. Incremented foreach instruction, the RP value provides the destination register
number, and the source register numbers are obtained bysubtracting the distance from RP. As shown in figure 3,
multiple instructions in a fetch group can be operated inparallel because the RP value for each instruction is rigidly
determined regardless of the operation of the preceding instruction. Therefore, the fetch width can extend as far as itis effective. The RP value returns to zero when it exceeds its
maximum value MAX RP.
Figure 3 also shows the mechanism related to SP. SP is
the only overwritable register and is operated by only the
SPADD instruction. As we designed the SPADD instructions
to require only an immediate operand, the instruction can
update the SP in order at the decode stage. Subsequently, the
SPADD instruction writes the copied SP value to its destination register, which can be performed in the OoO manner.
Guaranteeing multiple SPADDs in a fetch group requires thecascaded SPADD calculations in a cycle, which possibly affectthe clock frequency. The number of SPADD instructions in a
fetch group can be restricted by stalling and the performance^W Ɖƚƌ &ůĂŐƐƌĞĐŽǀĞƌǇ ƌĞĐŽǀĞƌǇ
ƌĞƋƵĞƐƚ /ŶƐƚ ƉŽƐŝƚŝŽŶ

ƌĞĐŽǀĞƌǇ

н,ĞĂĚZW,ĞĂĚϬ ϭƌĞƚŝƌĞ

н

Fig. 4. The mechanism of retire/recovery operation

effect of this stall is negligible because the SPADD interval isvery long (two per function call, at the most).
Next, the retire/recovery mechanism is shown in figure 4.
Composed of a circular FIFO structure, the ROB maintains
the information about each in-flight instruction. One entry
maintains the part of the architecture state that will be changedby the corresponding instruction. In STRAIGHT, the RP and
the PC of the instruction and the SP value at its decode time
are sufficient for an entry. Unlike the conventional architecture,
the retire operation only removes the completed instructions inorder from the head of the ROB unless the instruction causes
the exception or miss-recovery.
To reduce the hardware, each entry of the ROB does
not have to maintain the relevant RP. Only if the RP copy
corresponding to the ROB head is maintained, can the rest bederived from the entry position. In addition, storing the SP
value for each ROB entry is also redundant because the SP
updates are very rare. Providing a small table and maintaining
pointers for it in the ROB saves significant ROB capacity.
The recovery operation from the branch misprediction orother speculation is extremely simple compared to typicalsuperscalar architectures. Only one ROB entry read is sufficient. By using the destination register number of the oldest
instruction in the discarded path as a key, the SP and PC (thatis obtained by the execution result for branch misprediction
recovery) for the restart are obtained from the ROB. That

register number is also used for RP restoration. No ROB
updates are required except the tail pointer movement. This
operation is sufficient to ensure that the microarchitecturalchanges generated by the mispredicted instructions will beoverwritten eventually by the restarted correct path execution.
Although not mandatory, to save the power consumed byinvalid instructions, a partial flush of the scheduler, pipelined
functional units, and the load-store queue can be performed
using the corresponding RP value.
MAX RP physical registers are sufficient to avoid unexpected physical register aliasing because the register number
never exceeds that value. Here, one should consider deriving
the value of MAX RP to save the register values from the unexpected overwrites. When instruction k that uses k as the destination register number is about to retire, the value of register(k − the maximum distance) must still be maintained. Therefore, the corresponding number must not appear in RP before
the retirement of instruction k. Nevertheless, at that timethe youngest in-flight instruction receives the register number(k + the number of ROB entries). Thus, MAX RP is givenby (the maximum distance + the number of ROB entries).
As shown, STRAIGHT improves the efficiency of the OoO
execution by removing register renaming. Moreover, because
it eliminates the ROB walking penalty, STRAIGHT enables
the instruction window to be further increased. By eliminating
hotspots caused by register renaming, STRAIGHT can operate
at the same or higher frequency compared to the conventional
OoO superscalar processor with the same issue width and thesame number of functional units. Nevertheless, the architecture
does not prevent configuring the small efficient core. The
number of the physical register required is determined by the
ROB size and the maximum distance, therefore smaller corecan be configured by shrinking those values.
IV. STRAIGHT C OMPILER T ECHNOLOGY
A. Compilation Flow of STRAIGHT Compiler
The STRAIGHT compiler generates the STRAIGHT assembly where every source register is expressed as a distance. In
this section, we explain that any program is converted into
the STRAIGHT assembly correctly. We adopted LLVM IR
as the input of the STRAIGHT compiler. The advantage ofadopting it is that LLVM IR is an SSA-formed IR. Every
destination register in the SSA-formed IR is not overwritten
statically and this manner is similar to the register managementof STRAIGHT.
In the STRAIGHT architecture, every distance is calculatedby the number of in-order instructions between the producer
and consumer on the execution path. However, if any control
flow merges in the control statements including the if- andwhile- statements, the distance in each path can differ. In thiscase, the STRAIGHT compiler adds instructions such that the
distance is fixed, as described below.
B. Calling Convention
Basically, the STRAIGHT architecture stores arguments andreturns values in registers. Instructions that generate thosecallerproducer of arg0
producer of arg1…
JAL #callee
offsetcallee…
producer of retval0…
JR [dist. from JAL]

offsetfollowing instructions…

Fig. 5. Instruction Arrangement in Calling Convention

values are arranged in a fixed order defined by the function,
as shown in Figure 5. In this manner, any caller can pass
and receive the variables. For example, Figure 6 shows how
arguments and return values are passed. In this example, thecalling convention is to place the producer of argument arg1
just prior to the jump-and-link (JAL) instruction and place theproducer of arg0 just before it. As long as callers satisfy thisconvention, distances between an instruction in the callee toproducers of the argument are fixed regardless of which JAL
instruction is invoked. In the example, the instruction ADD[4] [3] in the callee always refers arg0 and arg1.
The return address is passed to the callee by the JAL
instruction that writes its PC+4 to its destination register. The
jump register (JR) instruction in the callee refers the JAL
instruction by the distance, which realizes the return operation.
Variable arguments such as printf in C language requires
are passed via stack frame. Calling conventions for System
calls are defined in a similar manner. Functions can be defined
to return one or multiple values by defining the distances
between the JR instruction and producers of return values.
For example, the ADDi [3] 1 instruction following the JR
instruction calculates retval0 plus 1.
If the producer instructions cannot be arranged as theconvention, the register move (RMOV) instructions are usedinstead. RMOV copies its source register value into its destination register, such that it can arrange the order of the produced
values.
Alive variables are stored in the stack frame using the SP
before the function call. The SP is incremented or decremented
by the SPADD instruction. SPADD instructions are generated
at the entrance and the exit of the function. LD and ST
instructions can access the stack frame by referring the relevant
SPADD instruction because SPADD writes the updated valueof SP into its destination register.
C. Code Generation
1) Operation Translation: Figure 7 shows the compilation
flow. The compilation process consists of three steps. First,

caller0

caller1 …

Producer of arg0
Producer of arg1
JAL #callee

Producer of arg0
Producer of arg1
JAL #callee

calleeBB0

BB0
producer

BB1
producer

producer
BB1

BB2
consumer

ADD [4] [3]consumerBB2（a）Producer of retval0
JR [dist. from JAL]BB0

ADDi [3] 1

producer

BB1

RMOV

consumer（b）

producer
RMOV

Fig. 6. Flows of Basic Blocks in Calling
C source

LLVM-IRBB2

STRAIGHT compiler
operationtranslation

distanceﬁxing

other languages

distancebounding

STRAIGHT code

Fig. 7. Flow of Compilation

the STRAIGHT compiler translates operations in LLVM IR
into those in STRAIGHT as the compiler for conventionalarchitectures. Some instructions are added or deleted in thisprocess because operations in LLVM IR and STRAIGHT do
not always correspond exactly.
2) Distance Fixing on Merging Flow: Here, the
STRAIGHT compiler adjusts distances from a consumer
instruction to producer instructions to the same length
regardless of the control flow. Any control flow is classified
as either branching or merging. Figure 8(a) shows that the
distances to the producer instruction are always fixed in thecase of branch. However, distances can differ in the case ofmerge, as shown in Figure 8(b). In this case, the STRAIGHT
compiler adds RMOVs at the tail of each merging basic block
to fix the distance basically, as shown in Figure 8(c).
These RMOVs are added by using the following algorithm.
First, the STRAIGHT compiler obtains the information on all
possible producers and corresponding merging basic blocks
from PHI instructions in LLVM IR. A PHI instruction isappeared when a operand has multiple producer candidates.
A distance also varies when there are multiple paths from one
producer instruction to its consumer. The information of suchproducers and merging basic blocks is obtained by livenessanalysis as well.
RMOVs are added at the tail of such merging basic blocks
to fix the distance regardless of the control flow. This process
is repeated as many times as the number of live variables.
RMOVs are stacked up on the tail of merging basic blocks

consumer（c）Fig. 8. Distances on control flows

not to change the distances that have been already fixed.
NOPs are also added to eliminate the distance differences thatare caused when there are fall-through paths. Although these
RMOVs appear to be redundant, the optimization described later
can reduce them.
Figure 9 shows an example of the fixed distances of thecounter variable in the loop statement. The counter variable isinitialized in the BB0 (ADDi [0] 0) and incremented before
the conditional statement in the BB2 (ADDi [4] 1). The
SLT at the head of the BB1 take the counter variable as its
source operand. There are two paths to this operand: from theBB0 and the BB2. The operand of SLTi is fixed as [2] byadding RMOVs.
3) Distance Bounding: The STRAIGHT architecture has
the maximum distance of source registers. Therefore, the
STRAIGHT compiler adds RMOVs that relay the values when
any distance exceeds the maximum. Each RMOV is added in thepossible maximum distance from the consumer avoiding theadded RMOVs. The STRAIGHT compiler repeats this processuntil every distance is equal to or less than the maximum.
D. Optimization specific to STRAIGHT
Thus far, the method that convert any program to the
STRAIGHT code that satisfies the requirement of the architecture is described. Furthermore, in addition to the basic
STRAIGHT code generation, the compiler can optimize thecode from the aspect of its specific register management.
We designed the redundancy elimination that reduces
RMOVs of which example is shown in the figure 10. (a), (b),and (c) are lists of STRAIGHT code that are compiled fromthe source code above with the different optimization level.
Here, “%%” in the list is a pseudo code which generates theindicated variables.
In the basic compilation algorithm, RMOVs are generated
proportionally to the number of live variables that are readBB0source code

ADDi [0] 0void iota( int arr[], int N ) {int i;
for( i = 0; i < N; ++i ) {arr[i] = i;}}

RMOV [1]NOPBB1SLTi [2] 100

STRAIGHT code

BEZ
BB2

ADDi [4] 1

BB3

RMOV [1]J BB1Fig. 9. Distance fixing of loop-statement

through the merging flows. For example, the loop body inthe figure 10(a) contains four RMOVs out of ten instructions.
The instructions only for fixing the distance occupy mostof the loops, which causes the performance degradation.
However, the distances can be fixed without adding RMOVs
by rearranging the producer instructions in most cases. In theexample of the figure10(b), two ADDi instructions can placeinstead of RMOVs because their result are not used within theiteration. Now those instructions generate values and adjust
distances at the same time. The number of RMOVs is reduced
to two out of eight instructions.
The figure 10(c) shows the other method to remove
the RMOV instruction. In the example, the return address“_RETADDR” is stored in the stack frame and loaded after theloop completion. In fact, the variable is never used during theloop execution, therefore the corresponding RMOV only relays
the variable. Storing such variables in the stack frame canreduces all RMOVs that only relay the variables. Now the loop
contains only one RMOV out of seven instructions. Generally,in cases where the variables are not read in the near future,
this method is effective.
V. E VALUATION M ETHOD
A. Simulated Models
STRAIGHT is a novel architecture that has different instruction sets and execution pipelines. To confirm its feasibility for executing application programs, we developed an
in-house cycle-accurate simulation environment. A compiler,
an assembler, a linker, and a cycle-accurate simulator aredeveloped. The simulator faithfully models all pipeline stagesof STRAIGHT, involving OoO scheduling, branch prediction,
memory dependency prediction, a load-store queue (LSQ)
for memory disambiguation, cache hit/miss prediction, thescheduler replay, a stream prefetcher for data caches, and themechanisms for the misprediction recovery.
We also compared STRAIGHT to the conventional superscalar to reveal whether this architecture improves the performance and efficiency. An in-house cycle-accurate simulator of
RISC-V (RV32IM) is also developed as a superscalar counterpart. The RAM based ROB is assumed in the evaluation.

%% arg0 : arr%% arg1 : N%% ̲RETADDR
Function̲iota :ADDi $ZERO, 0 # i = 0
RMOV [4]# &arr[0]RMOV [4]#N
RMOV [4]# ̲RETADDRRMOV [4]#iNOPLabel̲for̲cond :SLT [2] [4]
BEZ [1] Label̲for̲end
ST[4] [7]
ADDi [5] 1 # ++i
ADDi [9] 4 # &arr[i]RMOV [1]# &arr[i]RMOV [10] # N
RMOV [10] # ̲RETADDRRMOV [5]#iJLabel̲for̲cond
Label̲for̲end :
JR
[5]

（a）

%% arg0 : arr%% arg1 : N%% ̲RETADDR
Function̲iota :ADDi $ZERO 0 # i = 0
NOPLabel̲for̲cond :SLT [2] [4]
BEZ [1] Label̲for̲end
ST[4] [7]
ADDi [8] 4 # &arr[i]RMOV [8]#N
RMOV [8]# ̲RETADDR
ADDi [8] 1 # ++iJ
Label̲for̲cond
Label̲for̲end :
JR
[5]

（b）

%% arg0 : arr%% arg1 : N%% ̲RETADDR
Function̲iota :SPADD 4
ST [2] [1]
RMOV [5]# &arr[0]RMOV [5]#N
ADDi $ZERO 0 # i = 0
NOPLabel̲for̲cond :SLT [2] [3]
BEZ [1] Label̲for̲end
ST[4] [6]
ADDi [7] 4# &arr[i]RMOV [7]#N
ADDi [7] 1# ++i
JLabel̲for̲cond
Label̲for̲end :SPADD -4
LD
[1] 4
JR
[1]

（c）

Fig. 10. STRAIGHT code and optimization

The front-end is stalled if the walking has not been completed
when the first group of re-fetched instructions reaches tothe rename stage. The ROB-walking width is same as the
speed of frontend-width. Because the back-end pipeline of
STRAIGHT is similar to conventional superscalar processors,
both simulators can share common codes for the most part.
Therefore, this superscalar model is also provided with thesame state-of-art ILP technologies as described in above. As
the equalization to RV32IM, we set STRAIGHT as a 32bit
architecture and disabled the floating-point instructions andmodules in the evaluation.
The evaluated processor models and their parameters areshown in Table I. As shown, the sizes of each module are set
to the same value between the “SS” and “STRAIGHT” models
to clarify the comparison, which represent the superscalar and
STRAIGHT, respectively. We configure two classes named“4way” and “2way” to confirm the behavior of the different
typical design scales. “4way” models the high-end CPU coresfor desktop PCs and servers in which the OoO execution fully
shows its abilities. “2way” models smaller OoO cores for the
emerging mobile devices. The maximum distance is set to
31 in STRAIGHT-4way and STRAIGHT-2way models. Thisvalue is determined only for equalizing the number of the
ROB entries and the number of the physical registers to SS
parameters. The architecture’s optimal parameter can be different, however the parameter is set to clarify the comparison as
described above. As the instruction set is different from eachother, the performance is measured by the execution cycles
to complete the programs that are compiled from the same

L2 Cache
L3 Cache
Main Memory

source code.
Two standard benchmarks are used, Dhrystone 2.1 andCoreMark. Both are representative general-purpose integer benchmarks, which are suited to evaluate the novel
processor’s fundamental characteristics. The STRAIGHT
code is generated by our STRAIGHT compiler thattakes the LLVM IR code obtained by using clang 3.8
with -O2 and --target=mips-pc_linux-gnu -S-emit-llvm options as an input. The target option is
only for indicating the 32-bit architecture. The specific compiler front-end for STRAIGHT does not exist yet; however,currently the front-end for mips is sufficient to output anintermediate code for the STRAIGHT compiler back-end.
For both benchmarks, two STRAIGHT binaries are prepared;
STRAIGHT RAW that is generated by the basic algorithm
described in Section IV-A to IV-C and STRAIGHT RE+ thatis generated by adding the redundancy elimination describedin IV-D to STRAIGHT RAW.
For the comparison, clang/LLVM is also used for generating the RISC-V code. The back-end for LLVM bylowRISC is used. The code is generated with the -O2 and-march=rv32im --target=riscv32 option.
The cycles to complete the fixed number of iterations of thebenchmark program is measured: 9000 times for Dhrystone,
and 9 times for CoreMark. The performances are shown by
using the inverse of the execution cycles.
B. RTL Power Analysis
To reveal the improvement of the power efficiency, we
performed a power analysis in the register-transfer level (RTL).
The RTL description of STRAIGHT that faithfully models
the OoO execution, speculation, and recovery mechanisms
is developed as well as an in-house RTL description of

SS4wayDhrystone

STRAIGHT4way(RE+)

L1D Cache

STRAIGHT4way(RAW)L1I Cache

STRAIGHT4way(RE+)

Commit Width
Branch Predictor

STRAIGHT4way(RAW)Exec Unit

1.3
1.2
1.1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0

SS4wayISA
Fetch Width
Front-end latency
ROB Capacity
Scheduler
Register File
LSQ

2-way
4-way
STRAIGHTSS
STRAIGHT
STRAIGHT
RV32IMSTRAIGHT
2
6
8
6
8
6
64
224
2 way, 16 entries
4 way, 96 entries96
256
LD 48 / ST 48
LD 72 / ST 56
ALU 2, MUL 1,
ALU 4, MUL 2,
DIV 1, BC 2, Mem 2
DIV 1, BC 4, Mem 4
3
4
Gshare, Global History 10 bits, 32K entries
32 KiB, 4 way, 64 B line,
4 cycle hit latency
32 KiB, 4 way, 64 B line,
4 cycle hit latency
256 KiB, 4 way, 64 B line,
12 cycle hit latency
2 MiB, 4 way,
64 B line,
N/A
42 cycle hit latency
200 cycle latencySS
RV32IM

Relative Performance (Normalize to SS)

TABLE IEVALUATED MODELS

Coremark

Fig. 11. Performance comparison of STRAIGHT and SS (4way)

RV32I that involves the state-of-the-art superscalar technology.
Similar to our simulator, both descriptions use the common
code as much as possible for the comparison. In fact, the only
differences are the modules related to front-end stages and
ROB. The organizations of the RTL processors are almost thesame as that of STRAIGHT-2way and SS-2way in the table I;
however, the functions for integer multiply/divide instructions
and general system calls are omitted.
We confirmed that both RTL processors can execute a testcode correctly. The power consumed during the test code
execution is analyzed using the Joules RTL Power Solutionof Cadence. For both processors, the same recent advanced
technology node is assumed. The baseline clock frequencies
is set to be comparable to that of modern mobile processors.
Several clock frequencies are set for the evaluation, in which
the RTL processors are synthesized with the relevant time
constraint for each.
VI. E VALUATION
A. Performance Comparison to the Conventional Superscalar
Figure 11 shows the performance of STRAIGHT-4way andSS-4way. Each bar shows the relative performance that isnormalized to SS-4way. The white bars represent the performances of the superscalar processor and the black bars
represent those of STRAIGHT. STRAIGHT on Dhrystone
and STRAIGHT-4way RE+ on CoreMark show the better
performance than SS-4way, which are by 15.7% on Dhrystone
and 18.8% on CoreMark, respectively.
On the other hand, the possible overhead of STRAIGHTISA is shown in STRAIGHT-4way RAW on CoreMark that
degrades the performance by 4% from the baseline SS. The
reason is that a number of RMOV instructions are added by thebasic STRAIGHT compiler because CoreMark tends to havethe larger number of alive values through the execution thanDhrystone. However, the graph also shows that the overhead
can be reduced by the redundancy elimination algorithm, as
STRAIGHT-4way RE+ shows the best performance.
Figure 12 shows the performance comparison of
STRAIGHT-2way and SS-2way in the same manner. The
relative performance degradation of STRAIGHT-2way RAW
is larger than that of the four-way configuration. This is
as expected; in the current model, each RMOV instruction
behaves as one ALU instruction. The impact of increased
RMOV instruction becomes relatively large in the smaller
configuration. However, in this small OoO core configuration,
STRAIGHT-2way RE+ also shows a comparable or better
performance to its superscalar counterpart; it degrades theperformance by 7.4% from SS-2way on Dhrystone but
improves by 5.5% on CoreMark. The redundant elimination
algorithm is also effective for the smaller core.
As both architectures are configured to have the same
pipeline width, instruction window sizes, and predictors, thesignificant reasons for performance difference are as follows:i) ISA characteristics in STRAIGHT that eliminates register
overwrites by adding RMOV instructions or LD/ST instructions.
ii) STRAIGHT has fewer misprediction penalties because of
its recovery mechanism and shorter front-end pipeline. The
former can degrade the performance of STRAIGHT while thelatter improves the performance.
The impact of the rapid recovery of STRAIGHT is shownin Figure 13. The graph shows the performance of SS andSTRAIGHT RE+ as well as the performance when the misprediction penalty of SS is idealized to zero. Both 2way and4way performances on CoreMark are shown.
As shown in the graph, the effect of misprediction penalty issignificant for the superscalar. The effect is around 20% that issimilar amount to the reported in [14] on the integer programs
when RAM based RMT and ROB walking are configured.

STRAIGHT(RE+)

SS no penalty

SS

SS

2-way

STRAIGHT(RE+)

Fig. 12. Performance comparison of STRAIGHT and SS (2way)

Relative Performance (Normalize to SS 2-way)

STRAIGHT2way(RE+)

SS2waySTRAIGHT2way(RAW)Coremark

1.7
1.6
1.5
1.4
1.3
1.2
1.1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0

SS no penalty

Dhrystone

STRAIGHT2way(RE+)

STRAIGHT2way(RAW)

SS2wayRelative Performance (Normalize to SS)

1.2
1.1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0

4-way

Fig. 13. The effect of the misprediction penalty

Although the RMT technologies for reducing this penalty areexist, they increase the RMT power further. As the strong pointof STRAIGHT, it reduces this penalty with simple hardware
such that the performance and efficiency are both improved.
Branch prediction technologies can also reduce the recovery
penalty. To reveal this impact, we implemented TAGE predictor (8-component CBP-TAGE) [15] to our simulator. Figure 14
shows the relative performance of CoreMark when TAGE isused instead of the conventional gshare predictor. As expected,
relative performances of STRAIGHT is reduced for both 2way and 4-way because the performance of the baseline SS isrelatively improved by the reduced recovery penalty. However,
STRAIGHT-4way shows 10% better performance even in thisconfiguration. The basic characteristic is kept; STRAIGHT
shows comparable or better performance.
Next, figure 15 shows the number of executed instructions
on CoreMark to contrast code characteristics. Each bar isnormalized to the total instruction count of SS. The graphalso shows the fraction of instruction types for jump or branch,
ALU, LD/ST, RMOV, NOP, and others. The graph shows thatSTRAIGHT RAW requires more code than SS to complete
the same program. The increased instructions are shown to be
primarily RMOVs to adjust the distance. This is the possible
impact of the naive STRAIGHT ISA code in exchange for thesimpler hardware.
STRAIGHT RE+ reduces the instruction count drastically,
which shows the impact of the compiler technology for
STRAIGHT. The count of increased RMOVs are now reduced
to about 20% of the baseline SS. As the performance evaluation shows, the performance of STRAIGHT RE+ is better
than SS in the same issue-width for the most case. This means

1
0.9

2-way

STRAIGHT4way(RE+)

STRAIGHT4way(RAW)

SS4waySTRAIGHT2way(RAW)STRAIGHT2way(RE+)

Cumula ve Frac on

0.8

SS2wayRelative Performance (Normalize to SS)

1.2
1.1
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0

4-way

Fig. 14. Performance comparison of STRAIGHT and SS with TAGE branchpredictor

Number of Re!red Instruc!ons(Normalized to SS)

2.5

2

Others

0.7
0.6
0.5
0.4
0.3
0.2
0.1
Coremark

Dhrystone

0
1

2

4

8

16

32

64

128

Operand DistanceFig. 16. Cumulative Fraction of the Source Distance

The result indicates that the short operand field is sufficient
to represent the source distance. The distance limitation of
STRAIGHT ISA is not severe unless it is set to below 31.
This trend helps to reduce the STRAIGHT hardware resources
for physical registers as well as to shrink the instruction
length. We confirmed this by simulation with CoreMark.
The performance degradation is only around 1% when the
maximum distance is reduced from 1023 to 31.

NOP

1.5

RMOV

C. Power Reduction

ST
1

LD
ALU
Jump+Branch

0.5

0

SS

STRAIGHT(RAW)STRAIGHT(RE+)

Fig. 15. Fraction of the Retired Instruction Typethat the increased 20% instructions can be executed in parallel,
and they can utilize the empty issue slots that are reserved forthe maximum ILP.
B. The Sensitivity of STRAIGHT design parameters
Figure 16 shows the source distance distribution in the
cumulative graph. The distribution of source operand distancesis measured for all retired instructions. The code that is
generated with the uppermost distance limitation (1023) isused for this measurement. The actual maximum distance ofthe generated code is under 127 for each benchmark. The
graph shows that most of the distances between producer
instructions and consumer instructions are within 32. The
graph also shows that almost 40% of the source operands inDhrystone and 30% of those in CoreMark are the result of theprevious instruction.

Figure 17 shows the result of the RTL power analysis. The
relative powers of SS and STRAIGHT for various frequencies
from the baseline to 4.0 times of the baseline are shown. In
the graph the powers for the rename logic, the register file, and“other modules” are shown normalized to the corresponding
power of SS when operated in the baseline frequency. “Other
modules” involves the rest of the core, but caches, the buses,
and the branch predictor are not included. The White bars
indicate SS and the black bars indicate STRAIGHT. For“rename logic” of STRAIGHT, the power of the circuit for
operand determination (fig 3) is shown as the counterpart.
As clearly shown in the graph, the power corresponding register renaming is almost removed in STRAIGHT. The power
efficiency of STRAIGHT is supported because this poweris known to one of the major factors of recent processors’
power dissipation. The effect increases as the frequency. For
the reference, the proportion of the renaming power is 5.7%
to the other modules in this analysis. Because the scale of
the analyzed processor is small, the proportion will increase
when the wider front-end width is configured or check point
is introduced to reduce the miss-recovery.
The power of the register file and other modules show theslight increase in STRAIGHT. The amount is under 18% for
the register file and under 5% for other logics. This is the effectof the increased instructions per cycle (IPC) of STRAIGHT.

Rela!ve Power (normalized to SS 1.0x)

4.5
4
3.5

SS
STRAIGHT

3
2.5
2
1.5
1
0.5
0
1.0x

2.5x

4.0x

Rename Logic

1.0x

2.5x

4.0x

1.0x

2.5x

4.0x

Register File
Other Modules
Modules and Clock Frequency

Fig. 17. Relative Power of SS and STRAIGHT with various clock frequency

For the aspect of energy, the performance improvement cancels
this increase by the reduced execution time.
VII. R ELATED W ORKS
The single-thread performance is intensively researched byvarious approaches because of its significance. While thesuperscalar architecture achieves the sophisticated OoO execution with the support of register renaming, scheduling, deep
pipelining, smart cache managements, and various predictors,
its complexity and power consumption per instruction are
major drawbacks.
The limitation and optimization of the superscalar pipeline
depth are comprehensively explored around the turn of the
century [16] [17] [18], which enforces researchers to explore
novel ILP architectures as well as effective microarchitectures.
Scalable ILP architectures such as clustered architectures areexamples of the representative approaches [13] [19] [20]. Theirbasic idea is to separate the wide-issue core into several
execution blocks to maintain the critical loops short regardlessof the entire processor’s scale.
The single-thread program often lacks parallelism to fully
utilize such wide-issue cores. Speculative multithreading [21][22] technologies are presented to supply many instruction
streams to the core(s) by speculatively separating a singlethreaded program into multiple threads. Slipstream processors[23] and Runahead execution [24] are similar but more drastic
technologies that utilize helper threads only for the training ofpredictors and caches.
For the recent heterogeneous multicore processors, the technology for “OoO performance with in-order power” is desired
for the total chip performance improvement. Kumar et al. [25]showed the potential of heterogeneous multicore architectures
to improve the efficiency of a single-thread execution byswitching the dedicated core dynamically. Different scale coresthat share the same ISA are implemented in a chip, and an
adequate core is selected depending on the ILP amount of
the thread. It is known that the adequate configuration for the
program changes in less than a thousand instructions [26].
Composite cores [27] or FXA [28] introduces both OoO andin-order mechanisms into a core to enable rapid switching.
Mirage Core [12] virtually increases the number of OoO coresby transferring the scheduled instructions to the smaller inorder (OinO) cores.
As discussed, register renaming increases the OoO core’s
power consumption as well as it affect the clock frequency
by introducing the critical-loop into the front-end pipeline.
Safi et al. [10] proposes the two-stage pipelined renaming
logic to reduce both the power and frequency overheads.
Vajapeyam et al. [29] proposed the renamed trace cache (RTC)
to cache renamed operands. Shioya et al. [11] introduced the
distance representation into RTC to extend the caching target.
Although conventional RMT is required for the RTC miss,both approaches have the advantage of compatibility.
TILE architectures target both the simple hardware andwider execution of single-thread performance. By introducing
a specific ISA, the architecture maps the dataflow graph almost
directly onto its ALU networks [30] [31]. A hybrid approachhas been introduced to increase its viability [32].
The concept of STRAIGHT [7] reduces the required hardware and improves the performance and power efficiency
by leveraging the compiler support. Unlike VLIWs [33],which also leverages compiler technologies, its schedulingis performed by the hardware, which enables dynamic andspeculative ILP execution.
The instruction format of STRAIGHT has partially similar characteristics to instruction representations of dataflow
architectures [34] [35] [36] in those an operand is represented as a connection between a producer instruction anda consumer instruction. Unlike RISC architectures, a register
number (name) is not essential for both dataflow architectures
and STRAIGHT; and a value in a register is automaticallydiscarded in a short period. In STRAIGHT, this property leads
to the simple hardware structure because temporal values canbe maintained in a queue structure instead of a map structure.
The mechanism to pass the live variables across code
blocks often becomes a challenge in such designs because
the producer-consumer relation is not so simple in that case.
STRAIGHT’s approach is to statically prepare code that equalizes the relative distance between a consumer and producers sothat the operand fetch behavior is fixed regardless of execution
paths. The use of such relative distance is also seen in hybrid dataflow architecture SINAN [37] that passes arguments
according to the relative position in the data segment toimprove the inter-block communication. Contrary to typical
dataflow architectures where a producer instruction specifies
its destinations, the direction is inverse in STRAIGHT, that is,a consumer instruction refers to the source at its execution.
This design can avoid the fanout problem but requires abroadcast mechanism in the scheduler.
Same as RISC architectures, the execution model of
STRAIGHT inherits control flow guided by PC, which enables
to exploit speculations for pumping instructions into the deep
fast pipeline without waiting for actual execution. The twodifferent approach, dataflow and control flow, are bound at
the instruction level by RP that is incremented by the control
flow and is used as a data pointer. Contrast to the typical
dataflow architectures which require hierarchical structure ofinter-block and intra-block, this instruction level unification
makes STRAIGHT a simple flat architecture.
VIII. C ONCLUSION
Herein, we presented the practical STRAIGHT architecture
by describing its ISA specification, microarchitecture organization, and compiler algorithm. By indicating source operands
based on the distance from the producer instruction, the ISA
guarantees that each register will be written once and thendiscarded in a fixed period. These characteristics enable thedesign of a novel microarchitecture that eliminates register
renaming while maintaining a flexible OoO execution. The
compiler algorithm that generates code for this novel ISA is
first revealed. The key idea is to arrange the alive variables
in a fixed order regardless of the control flow variation. The
performance is evaluated with a cycle-accurate simulator; thepower consumption is evaluated by the RTL power analysis.
The same sized superscalar counterpart is also developed forthe comparison.
The evaluation result shows that STRAIGHT achieves ahigher performance with the simpler hardware. It shows 18.8%
better performance than its superscalar counterpart. The low
misprediction penalty delivered by STRAIGHT’s simple hardware supports the superiority. The unique ISA of STRAIGHT
possibly deteriorates the performance with the naive compiler,
however, we also revealed that our redundancy elimination
resolves the overhead. STRAIGHT shows better performance
than the superscalar processor in the small configuration as
well, which demonstrates its suitability for mobile platforms.
The RTL power analysis shows that STRAIGHT reduces thepower consumption by removing the power for renaming.
Therefore the architecture achieves the performance improvement with the lower energy by the simple hardware. The
results support that the architecture is a novel viable alternativefor designing general purpose OoO processors.
ACKNOWLEDGMENT
Authors would like to thank Akifumi Fujita for the first
implementation of our RTL description, and also thank Makoto
Sahoda for the first implementation of the STRAIGHT simulator.
R EFERENCES[1] M. D. Hill and M. R. Marty, “Amdahl’s law in the multicore era,” IEEE
Computer, vol. 41, 2008.
[2] H. Esmaeilzadeh, E. Blem, R. St. Amant, K. Sankaralingam, and
D. Burger, “Dark silicon and the end of multicore scaling,” IEEE Micro,
vol. 32, 2012.
[3] J. Nickolls and W. J. Dally, “The gpu computing era,” IEEE Micro,
vol. 30, 2010.
[4] P. Lotfi-Kamran, B. Grot, M. Ferdman, S. Volos, O. Kocberber, J. Picorel, A. Adileh, D. Jevdjic, S. Idgunji, E. Ozer, and B. Falsafi, “ScaleOut Processors,” in Int. Symp. on Computer Architecture, 2012.
[5] B. K. Rosen, M. N. Wegman, and F. K. Zadeck, “Global Value Numbers
and Redundant Computations,” in Symp. on Principles of Programming
Languages, 1988.
[6] B. Alpern, M. N. Wegman, and F. K. Zadeck, “Detecting Equalityof Variables in Programs,” in Symp. on Principles of Programming
Languages, 1988.

[7] H. Irie, D. Fujiwara, K. Majima, and T. Yoshinaga, “STRAIGHT:
Realizing a Lightweight Large Instruction Window by using Eventually
Consistent Distributed Registers,” in Int. Workshop on Challenges on
Massively Parallel Processors, 2012.
[8] C. Lattner and V. Adve, “Llvm: a compilation framework for lifelong
program analysis transformation,” in Int. Symp. on Code Generation and
Optimization, 2004.
[9] A. Moshovos, “Checkpointing alternatives for high-performance, poweraware processors,” in Int. Symp. on Low Power Electronics and Design,
2003.
[10] E. Safi, A. Moshovos, and A. Veneris, “Two-stage, pipelined register
renaming,” IEEE Trans. on Very Large Scale Integration Systems,
vol. 19, 2011.
[11] R. Shioya and H. Ando, “Energy efficiency improvement of renamed
trace cache through the reduction of dependent path length,” in Int.
Conference on Computer Design, 2014.
[12] S. Padmanabha, A. Lukefahr, R. Das, and S. Mahlke, “Mirage cores:
The illusion of many out-of-order cores using in-order hardware,” in Int.
Symp. on Microarchitecture, 2017.
[13] S. Palacharla, N. P. Jouppi, and J. E. Smith, “Complexity-Effective
Superscalar Processors,” in Int. Symp. on Computer Architecture, 1997.
[14] S. Petit, R. Ubal, J. Sahuquillo, and P. Lopez, “Efficient register
renaming and recovery for high-performance processors,” IEEE Trans.
on Very Large Scale Integration Systems, vol. 22, 2014.
[15] A. Seznec, “A new case for the tage branch predictor,” in Int. Symp. on
Microarchitecture, 2011.
[16] V. Agarwal, M. S. Hrishikesh, S. W. Keckler, and D. Burger, “Clock Rateversus IPC: The End of the Road for Conventional Microarchitectures,”in Int. Symp. on Computer Architecture, 2000.
[17] M. S. Hrishikesh, D. Burger, N. P. Jouppi, S. W. Keckler, K. I. Farkas,
and P. Shivakumar, “The optimal logic depth per pipeline stage is 6 to
8 fo4 inverter delays,” in Int. Symp. on Computer Architecture, 2002.
[18] A. Hartstein and T. R. Puzak, “Optimum power/performance pipeline
depth,” in Int. Symp. on Microarchitecture, 2003.
[19] R. Canal, J. M. Parcerisa, and A. Gonzalez, “Dynamic Cluster Assignment Mechanisms,” in Int. Symp. on High-Performance Computer
Architecture, 2000.
[20] A. Baniasadi and A. Moshovos, “Instruction Distribution Heuristics for
Quad-Cluster Dynamically-Scheduled, Superscalar Processors,” in Int.
Symp. on Microarchitecture, 2000.
[21] G. Sohi, S. Breach, and T. Vijaykumar, “Multiscalar processors,” in Int.
Symp. on Computer Architecture, 1995.
[22] V. Krishnan and J. Torrellas, “A chip-multiprocessor architecture with
speculative multithreading,” IEEE Trans. on Computers, vol. 48, 1999.
[23] Z. Purser, K. Sundaramoorhy, and E. Rotenberg, “A Study of Slipstream
Processors,” in Int. Symp. on Microarchitecture, 2000.
[24] O. Mutlu, J. Stark, C. Wilkerson, and Y. N. Patt, “Runahead execution:
An effective alternative to large instruction windows,” IEEE Micro,
vol. 23, 2003.
[25] R. Kumar, K. I. Farkas, N. P. Jouppi, P. Ranganathan, and D. M.
Tullsen, “Single-isa heterogeneous multi-core architectures: the potential
for processor power reduction,” in Int. Symp. on Microarchitecture, 2003.
[26] H. H. Najaf-abadi and E. Rotenberg, “Architectural contesting,” in Int.
Symp. on High Performance Computer Architecture, 2009.
[27] A. Lukefahr, S. Padmanabha, R. Das, F. M. Sleiman, R. Dreslinski, T. F.
Wenisch, and S. Mahlke, “Composite cores: Pushing heterogeneity into
a core,” in Int. Symp. on Microarchitecture, 2012.
[28] R. Shioya, M. Goshima, and H. Ando, “A front-end execution architecture for high energy efficiency,” in Int. Symp. on Microarchitecture,
2014.
[29] S. Vajapeyam and T. Mitra, “Improving superscalar instruction dispatch
and issue by exploiting dynamic code sequences,” in Int. Symp. on
Computer Architecture, 1997.
[30] R. Nagarajan, K. Sankaralingam, D. Burger, and S. Keckler, “A design
space evaluation of grid processor architectures,” in Int. Symp. on
Microarchitecture, 2001.
[31] M. B. Taylor, W. Lee, J. Miller, D. Wentzlaff, I. Bratt, B. Greenwald,
H. Hoffmann, P. Johnson, J. Kim, J. Psota, A. Saraf, N. Shnidman,
V. Strumpen, M. Frank, S. Amarasinghe, and A. Agarwal, “Evaluationof the Raw Microprocessor: An Exposed-Wire-Delay Architecture for
ILP and Streams,” Int. Symp. on Computer Architecture, 2004.
[32] T. Nowatzki, V. Gangadhar, and K. Sankaralingam, “Exploring thepotential of heterogeneous von neumann/dataflow execution models,”in Int. Symp. on Computer Architecture, 2015.

[33] A. Nicolau and J. A. Fisher, “Measuring the parallelism available
for very long instruction word architectures,” IEEE Trans. Computers,
vol. 33, 1984.
[34] J. Dennis and D. Misunas, “A preliminary architecture for a basic dataflow processor,” in Annual Symp. on Computer Architecture, 1975.
[35] J. Dennis and G. Gao, “An efficient pipelined dataflow processor
architecture,” in Conf. on Supercomputing, 1988.
[36] Arvind and R. Nikhil, “Executing a program on the mit tagged-token
dataflow architecture,” IEEE Trans. on Computers, vol. 39, 1990.
[37] S. Onder and R. Gupta, “Sinan - a forwarding multithreaded architecture,” in Int. Conf. on High-Performance Computing, 1995.