Dynamic Vectorization in the E2 Dynamic Multicore Architecture To appear in the proceedings of HEART 2010
Andrew Putnam Aaron Smith Doug Burger Microsoft Research Microsoft Research Microsoft Research [email protected] [email protected] [email protected]
ABSTRACT TFlex [9] is one proposed architecture that demonstrated a Previous research has shown that Explicit Data Graph Exe- large dynamic range of power and performance by combin- cution (EDGE) instruction set architectures (ISA) allow for ing power efficient, lightweight processor cores into larger, power efficient performance scaling. In this paper we de- more powerful cores through the use of an Explicit Data scribe the preliminary design of a new dynamic multicore Graph Execution (EDGE) instruction set architecture (ISA). processor called E2 that utilizes an EDGE ISA to allow for TFlex is dynamically configurable to provide the same per- the dynamic composition of physical cores into logical pro- formance and energy efficiency as a small embedded proces- cessors. We provide details of E2’s support for dynamic re- sor or to provide the higher performance of an out-of-order configurability and show how the EDGE ISA facilities out- superscalar on single-threaded applications. of-order vector execution. Motivated by these promising results, we are currently designing a new dynamic architecture called E2 that uti- lizes an EDGE ISA to achieve high performance power effi- Categories and Subject Descriptors ciently [3]. The EDGE model divides a program into blocks C.1.2 [Computer Systems Organization]: Multiple Data of instructions that execute atomically. Blocks consist of a Stream Architectures—single-instruction-stream, multiple- sequence of dataflow instructions that explicitly encode re- data-stream processors (SIMD), array and vector proces- lationships between producer-consumer instructions, rather sors; C.1.3 [Computer Systems Organization]: Other Ar- than communicating through registers as done in a conven- chitecture Styles—adaptable architectures, data-flow archi- tional ISA. These explicit encodings are used to route operands tectures to private reservation stations (called operand buffers) for each instruction. Registers and memory are only used for General Terms handling less-frequent inter-block communication. Prior dynamic architectures [7, 9] have demonstrated the Design, Performance ability to take advantage of task and thread-level parallelism, but handling data-level parallelism requires dividing data into Keywords independent sets and using thread-level parallelism. In this Explicit Data Graph Execution (EDGE) paper we focus on efficiently exploiting data-level parallelism, even without threading, and present our preliminary vector unit design for E2. Unlike previous in-order vector ma- 1. INTRODUCTION chines, E2 allows for out-of-order execution of both vectors Chip designers have long relied on dynamic voltage and and scalars. frequency scaling (DVFS) to trade off power for performance. The E2 instruction set and execution model supports three However, voltage scaling no longer works as processors ap- new capabilities that enable efficient vectorization across a proach the minimum threshold voltage (Vmin) as frequency broad range of codes. First, by slicing up the statically pro- scaling at Vmin reduces both power and performance lin- grammed issue window into vector lanes, highly concurrent, early, achieving no reduction in energy. Power and perfor- out-of-order issue of mixed scalar and vector operations can mance trade-offs are thus left to either the microarchitecture be achieved with lower energy overhead than scalar mode. or the system software. Second, the statically allocated reservation stations permit When designing an architecture with little (if any) DVFS, the issue window to be treated as a vector register file, with designers must choose how to spend the silicon resources. wide fetches to memory and limited copying between a vec- Hill and Marty [6] described four ways that designers could tor load and the vector operations. Third, the atomic block- use these resources: (1) many small, low performance, power based model in E2 permits refreshing of vector (and scalar) efficient cores, (2) few large, power inefficient, high per- instruction blocks mapped to reservation stations, enabling formance cores, (3) a heterogeneous mix of both small and repeated vector operations to issue with no fetch or decode large cores, and (4) a dynamic architecture capable of com- energy overhead after the first loop iteration. Taken together, bining or splitting cores to adapt to a given workload. Of these optimizations will reduce the energy associated with these alternatives, the highest performance and most energy finding and executing many sizes of vectors across a wide efficient design is the dynamic architecture. Hill and Marty range of codes. characterized what such a dynamic processor could do but did not describe the details of such an architecture. prnst n te ntuto ntebok n l but all and block, the in instruction other any to operands and used. identifiers the store encode of sin- to set and a the block, that and every writes ensure from register to produced compiler is commit, branch the simplify gle on large To relies form architecture instructions. to the useful predication with improve filled uses To blocks compiler [12]. the semantics blocks performance, memory identifiers into store sequential and programs enforce load break to assign and to instructions compiler hard- dataflow The of the stores. instruc- on and 128 loads relies 32 and ware most at 4 execute between may and sub- contain tions execution Blocks they executing. the finished variable-size: to are are blocks blocks when detect maps and that strate hardware the plify complexity. hardware vector high additional for little allows with lanes throughput into window innova- the breaking This single- of cycle). two tion per or calculations 16- cycle, point per four floating operations precision 8-bit, integer 32-bit (eight two execution or as bit, SIMD bank operations, fine-grained point one as floating and and well file. integer ALU register both 64-bit and support buffers, ALUs a operand window, of instruction the consisting of lane each with core. physical diagram one block of a structure and internal cores, the 32 of containing architecture processor basic E2 the shows an 1 of scalabil- Figure simplicity, tolerance. namely fault - bene- and architectures ity, the tiled with other E2 of provides design fits by This network. connected on-chip cores an processing decentralized performance, ARCHITECTURE operand E2 windows, THE instruction the and down, 2. powered are lanes. 4 operations, two and point other 3 floating the lanes and to in integer available ALUs both made for are the lanes, registers ALU mode, vector and independent an scalar buffers, four buffers, In of operand composed registers. 64-bit is 16 two core window, and each 32-instruction mode, vector a In with diagram. each block microarchitecture E2 1: Figure 2crsoeaei w xcto modes: execution two in operate cores E2 sim- to ways several in blocks restricts ISA EDGE E2’s four), choose we paper this (in lanes N contains core A high power, low of consists that architecture tiled a is E2 vector oe nsaa oe n ntuto a send can instruction any mode, scalar In mode. "2 "2 "2 "2 $ $ $ $ "2 "2 "2 "2 $ $ $ $ 8-); 8-); 8-); 8-); 8-); 8-); 8-); 8-); $ $ $ $ $ $ $ $ 8-); 8-); 8-); 8-); 8-); 8-); 8-); 8-); $ $ $ $ $ $ $ $ 8-); 8-); 8-); 8-); 8-); 8-); 8-); 8-); $ $ $ $ $ $ $ $ 8-); 8-); 8-); 8-); 8-); 8-); 8-); 8-); $ $ $ $ $ $ $ $ %&'()*+(,-&$ @);/,+(-) scalar 8-&()-? =)9&+:$ 89+:; 12$ "7$ $ < = $ $ $ $ mode %&'()*+(,-&$ %&'()*+(,-&$ %&'()*+(,-&$ %&'()*+(,-&$ 12$3$456 .,&/-0 12$3$456 .,&/-0 12$3$456 .,&/-0 12$3$456 .,&/-0 $ $ $ $ $ $ $ $ u ic ny6 eitr r upre yteIA the reduce ISA, to the gated by powered supported is consumption. power capacity are file registers interleaved, register 64 similarly additional only are files since L1 register the but be- The doubling choose effectively to capacity. caches, address cache physical the physi- of two two bit the of additional tween composed an core uses logical cores com- cal a physical example, the composed For core the logical all cores. the of give resources computational to bined cores physical the among called is ing together in- cores from Merging blocks threads. can dependent instruction processor execute physical and large each independently so same work split the be when can available, Or, processor is logical superscalar. parallelism aggressive thread-level an by ample like handled performs proces- be logical that large can sor one workload into core a physical every of composing portions powerful serial more larger, example, form de- to at runtime cores at of more number or decomposing and one and size time, sign the composing fixing architec- by than Rather the workload cores. given adapt a dynamically for to ture ability the is processors Cores Composing 2.1 to quickly basis. in adapt block-by-block bit to a a core on from phases each application allows basis different This per-block lane. header. a vector block on same the determined the is in mode vec- instructions The In to operands power. conserve send to only all off turned mode, are tor ALUs the of two AB;)9&/ AB;)9&/ AB;)9&/ AB;)9&/ 12$3$D56 12$3$D56 12$3$D56 12$3$D56 =*CC;) =*CC;) =*CC;) =*CC;) ahisrcinboki apdt igepyia pro- physical single a to mapped is block instruction Each memory and registers to accesses interleave cores Logical other from E2 distinguishes that characteristic key One oe,wiesltigcrsi called is cores splitting while cores, $ $ $ $ $ $ $ $ $ $ $ $ AB;)9&/ AB;)9&/ AB;)9&/ AB;)9&/ 12$3$D56 12$3$D56 12$3$D56 12$3$D56 =*CC;) =*CC;) =*CC;) =*CC;) $ $ $ $ $ $ $ $ $ $ $ $ N Lsaetre n u ntutoscan instructions but on, turned are ALUs 8-&()-??;) %&(;)C9+;$ M;N-)O$ !"#$ !"#$ !"#$ !"#$ physical $ E;F,'(;)'$ E;F,'(;)'$ E;F,'(;)'$ E;F,'(;)'$ 7D$3$D56 7D$3$D56 7D$3$D56 7D$3$D56 G5L G12 G7D GH oe a emre together merged be can cores I I I 74J I D1J 5KJ 17J $ $ $ $ $ $ $ $
"7$>9(9$89+:; $ "9&;$5 $ "9&;$1 $ "9&;$2 $ "9&;$7 12$<= decomposing $ logical $ "-9/PQ(-);$ R*;*; $ $ oe.For cores. compos- cores. cessor. When composed, the architecture uses additional Component Parameters Area (mm2) % Area cores to execute speculative instruction blocks. When the Instruction Window 32x54b 0.08 2% non-speculative block commits, it sends the commit signal Branch Predictor 0.12 3% along with the exit branch address to all other cores in the Operand Buffers 32x64b 0.19 5% logical processor. Speculative blocks on the correct path ALUs 4 SIMD, Int+FP 0.77 20% continue to execute, while blocks on non-taken paths are Register File 64 x 64b 0.08 2% squashed. Details of this process are discussed further in Load-Store Queue 0.19 5% section 2.2.1. L1 I-Cache 32kB 1.08 28% Core composition is done only when the overhead of chang- L1 D-Cache 32kB 1.08 28% ing configurations is outweighed by the performance gains Control 0.19 5% of a more efficient configuration. Composition is always Core 3.87 100% done at block boundaries and is initiated by the runtime sys- L2 Cache 4MB 100 tem. To increase the number of scenarios in which composi- tion is beneficial, E2 provides two different ways to compose Table 1: E2 core components, design parameters, and cores, each offering a different trade-off in overhead and ef- area. ficiency. Full composition changes the number of physical cores in a logical core, and changes the register file and cache The oldest instruction block then becomes the non-speculative mappings. Dirty cache lines are written out to main mem- block. Any blocks that were not correctly speculated are ory lazily. Logical registers and cache locations are dis- squashed. This taken branch signal differs from the commit tributed evenly throughout the physical cores. Cache lines signal. The taken branch allows the next block to continue are mapped via a simple hash function, leading to a larger speculation and begin fetching new instruction blocks. How- logical cache that is the sum of the cache capacities of all ever, register and memory values are not valid until after the physical cores. commit signal. Quick composition adds additional cores to a logical pro- 2.2.2 Speculation Within a Block cessor, but retains the same L1 data cache and register map- There are three types of speculation within an instruction pings, and does not write dirty cache lines out to main mem- block. Predicate speculation uses the combined predicate- ory. This leaves the logical processor with a smaller data branch predictor to predict the value of predicates. Mem- cache than possible with full composition, but ensures that ory speculation occurs in speculative blocks when the spec- accesses to data already in the cache will still hit after com- ulative block loads values from the L1 cache that may be posing. Quick composition is the most useful for short-lived changed by less-speculative blocks. Load speculation occurs bursts of activity where additional execution units are use- when the load-store queue (LSQ) allows loads to execute be- ful, but where the overhead of reconfiguring the caches is fore stores with lower load-store identifiers have executed. greater than the savings from a larger, more efficient cache In all three cases, mis-speculation requires re-execution of configuration. the entire instruction block. This is relatively lightweight Decomposition removes physical cores from a logical pro- and only requires invalidating the valid bits in all of the cessor and powers the removed cores down to conserve en- operand buffers, and re-loading the zero operand instruc- ergy. Execution continues on the remaining physical cores. tions. Decomposition requires flushing the dirty lines of each cache being dropped from the logical processor and updating the 2.3 Area and Frequency cache mapping. Dirty cache lines in the remaining cores are We developed an area model for the E2 processor using written back only when a cache line is evicted. ChipEstimate InCyte [4] and an industry-average 65nm pro- cess technology library. The design parameters and compo- 2.2 Speculation nent areas are shown in Table 1. Each E2 core requires 3.87 It has long been recognized that speculation is an essential mm2, including L1 caches. piece of achieving good performance on serial workloads. Frequency estimates are not available using our version of E2 makes aggressive use of speculation to improve perfor- InCyte. However, the microarchitecture does not have any mance. A combined predicate-branch predictor [5] specu- large, global structures and uses distributed control through- lates at two levels. First, it predicts the branch exit address out the chip. Because of this, we expect that E2 will achieve for each block for speculation across blocks. Second, it pre- a comparable frequency to standard cell ARM multi-core dicts the control flow path within blocks by predicting the processor designs, which range from 600 to 1000 MHz in predicate values. 65nm [2]. 2.2.1 Speculation Across Blocks Predicting the branch exit address allows instruction blocks 3. EXECUTION PIPELINE to be fetched and begin executing before the current block E2’s execution is broken into three primary stages: in- has completed. The oldest instruction block is marked as struction fetch, execute, and commit. This section first de- non-speculative, and predicts a branch exit address. This ad- scribes the behavior of each stage when operating in scalar dress is fetched and begins executing on another physical mode, then describes the differences between scalar and vec- core in the logical processor or on the same physical core if tor mode. there is available space in the instruction window. The taken branch address often resolves before the block 3.1 Fetch completes. In this case, the non-speculative block notifies One of the primary differences between E2 and conven- the other cores in the logical processor of the taken address. tional architectures is that E2 fetches many instructions at once, rather than continually fetching single instructions. In- Element Size Minimum (1 ALU) Maximum (4 ALUs) structions Blocks of up to 128 instructions are fetched from 8-bit 8 32 the L1 instruction cache at a time and loaded into the instruc- 16-bit 4 16 tion window. Instructions remain resident in the window un- 32-bit 2 (1 single fp) 8 (4 single fp) til block commit (or possibly longer, as described in section 64-bit 1 4 3.3.1). Physical cores support one 128-instruction block, two 64- Table 2: Supported vector operations instruction blocks, or four 32-instruction blocks in the win- dow at the same time. Instruction blocks begin with a 128-bit block header containing: the number of instructions in the identifiers in the instruction block header so that the microar- block, flags for special block behavior, and bit vectors that chitecture can identify when criteria (2) is satisfied. encode the global registers written by the block and the store 3.3 Commit identifiers used. Instructions are 32-bits wide, and generally contain at least four fields: During execution, instructions do not modify the architec- tural state. Instead, all changes are buffered and commit to- • Opcode [9 bits]: The instruction to execute along with gether at block completion. Once the core enters the commit the number of input operands to receive. phase, the register file is updated with all register writes, and • Predicate [2 bits]: Indicates whether the instruction all stores in the load-store queue are sent to the L1 cache be- must wait on a predicate bit, and whether to execute ginning with the lowest sequence identifier. Once all register if that bit is true or false. writes and stores have committed, the core sends a commit • Target 1 [9 bits]: The identifier of the consumer for the signal to all other cores in the same logical processor. instruction’s result. If the consumer is a register, this 3.3.1 Refresh field is the register number. If the consumer is another instruction, this field contains the consumer’s instruc- One important commit optimization, called refresh, occurs tion number (used as an index into the operand buffer) when the instruction block branches back to itself. Rather and whether the result is used as operand 0, operand 1, than loading the instructions again from the L1 instruction or as a predicate. cache, the instructions are left in place and only the valid • Target 2 / Immediate [9 bits]: Either a second instruc- bits in the operand buffers and load-store queues are cleared. tion target, or a constant value for immediate instruc- This allows the instruction fetch phase to be bypassed en- tions. tirely. Instructions that generate constants can also pin val- ues in the operand buffers so that they remain valid after re- The instruction window is divided into four equal banks fresh, and are not regenerated each time the instruction block with each bank loading two instructions per cycle. Instruc- executes. tions that do not require input operands, such as constant generation instructions, are scheduled to execute immedi- 3.4 Vector Mode ately by pushing the instruction number onto the ready queue. Vector mode execution divides each processor core into N (in this paper 4) independent vector lanes. When operating 3.2 Execute in vector mode, instructions can only target other instruc- Execution starts by reading ready instruction numbers from tions in the same vector lane, eliminating the need for a full the ready queues. Operands, the opcode, and the instruction crossbar between operand buffers and ALUs. Each lane con- target fields are forwarded to either the ALUs, register file sists of a 32-entry instruction window, two 64-bit operand (for read instructions), or the load-store queue (for loads buffers, 16 registers, and one ALU. and stores). The target field is used to route the results (if E2 supports vector operations on 64-bit, 128-bit (padded any) back to the appropriate operand buffer (or to the regis- to 256-bits), and 256-bit wide vectors. Each ALU supports ter file, in the case of writes). eight 8-bit, four 16-bit, or two 32-bit vector operations. Four When results are forwarded back to the operand buffers, ALUs enable E2 to support up to 32 vector operations per the targeted instruction is checked to see which inputs are cycle per core. 64-bit vector operations utilize a single ALU, required, and which operands have already arrived. If all where as 128- and 256-bit vector operations utilize all four operands for the instruction have arrived, the instruction num- ALUs. Table 1 lists the number of parallel vector operations ber is added to the ready queue. Execution continues in this supported for each vector length and data element size. data-driven manner until the block is complete. Instruction blocks containing vector instructions are lim- Like other EDGE and dataflow architectures, special han- ited to 32 instructions which is the size of the instruction dling is required for loads and stores to ensure that memory window for each vector lane. Vector instructions issuing in operations follow the program order semantics of imperative lane 1 are automatically issued in the other three lanes and language programs. E2 uses the approach described in [10], scalar instructions are always assigned to lane 1. where the compiler encodes each memory operation with a In vector mode, the sixty-four 64-bit physical registers (R0 sequence identifier to denote program order that the microar- - R63) are aliased to form sixteen 256-bit vector registers chitecture uses to enforce sequential memory semantics. (V0 - V15). We divide the physical register file into four Not all instructions in a block necessarily execute because banks to support single cycle access for vectors. of predication, so the microarchitecture must detect block completion. Blocks are considered complete when (1) one 3.4.1 Memory Access in Vector Mode (and only one) branch has executed, and (2) all instructions E2 cores operate on vectors in 256-bit chunks, which en- that modify external state (register writes and stores) have ables efficient exploitation of data-level parallelism on small executed. The compiler encodes the register writes and store and medium-length vectors. Operating on larger vectors is done using multiple instruction blocks in a loop, using the 1 // numVectors > 0 efficient refresh mode to bypass instruction fetch and the 2 // y = r * .299 + g * .587 + b * .114; generation of constants (section 3.3). 3 void rgb2y(int numVectors, Splitting larger vectors among multiple instruction blocks 4 __vector float *r, __vector float *g, 5 __vector float *b, __vector float *y) could introduce a delay between loads of adjacent chunks 6 { of the same vector, as those loads are split among multiple 7 __vector float yr = { 0.299f, 0.299f, instruction blocks. To mitigate this delay, E2 employs a spe- 8 0.299f, 0.299f }; cialized unit called the memory interface controller (MIC). 9 __vector float yg = { 0.587f, 0.587f, The MIC takes over control of the L1 data cache, chang- 10 0.587f, 0.587f } ; ing part of the cache into a prefetching stream buffer [8,11]. 11 __vector float yb = { 0.114f, 0.114f, 12 0.114f, 0.114f }; Stream buffers predict the address of the next vector load 13 and bring that data into the cache early. This ensures that the 14 for (int i = 0; i < numVectors; i++) vector loads in subsequent instruction blocks always hit in 15 y[i] = r[i] * yr + g[i] * yg + b[i] * yb; the L1 cache. 16 } Since vector and scalar operations are mixed in instruction 17 blocks, part of the cache still needs to operate as a traditional 18 _rgb2y: 19 read t30, r3 // numVectors cache. Rather than halve the size of the cache, the set asso- 20 read t20, r4 // address of next r ciativity of the cache is cut in half – converting those ways 21 read t21, r5 // address of next g into the memory for a stream buffer. On vector loads, the 22 read t22, r6 // address of next b cache checks the stream buffer. On scalar loads and stores, 23 read t32, r7 // address of y the cache checks the cache in the same manner, albeit with a 24 read t31, r8 // i reduced number of sets to check. 25 read t1, v0 // vector yr 26 read t3, v1 // vector yg Vector store instructions are buffered in the stream buffer 27 read t5, v2 // vector yb until block commit, at which point they are written directly 28 out to main memory. 29 // RGB to Y conversion 30 vl t0, t20 [0] // vector load 31 vl t2, t21 [1] 4. EXAMPLE: RGB TO Y CONVERSION 32 vl t4, t22 [2] In this section we give an example to explain how a pro- 33 vfmul t6, t0, t1 // vector fp mul gram is vectorized on E2. Figure 2 shows the C code and 34 vfmul t7, t2, t3 corresponding vectorized assembly for a RGB to Y bright- 35 vfmul t8, t4, t5 ness conversion which is commonly used to convert color 36 vfadd t9, t6, t7 // vector fp add 37 vfadd t10, t8, t9 images to grayscale. Each pixel in an image has a triple 38 corresponding to the red, green, and blue color components. 39 // store result in Y Brightness (Y) is computed by multiplying each RGB value 40 multi t40, t31, #32 by a constant and summing the three results. This program 41 add t41, t32, t40 can be trivially parallelized to perform multiple conversions 42 vs 0(t41), t10 [3] // vector store in parallel since each conversion is independent. 43 44 // loop test 45 tlt t14, t31, t30 4.1 C Source 46 ret_t
4.2 Assembly Vector instructions begin with ’v’ (lines 30-37 and 42). All The assembly listing is given in lines 18-51. Instructions load and store instructions are assigned load-store identifiers are grouped into blocks by the compiler (one block for this to ensure sequential memory semantics (lines 30-32 and 42). example) and a new block begins at every label (line 18). That is a load assigned ID0 must complete before a store The architecture fetches, executes, and commits blocks atom- with ID1. ically. By convention we use Rn to denote scalar registers, Most instructions can be predicated and predicates are only Vn to denote vector registers, and Tn to denote temporary visible within the block they are defined. Predicated instruc- operands. The scalar and vector registers are part of the tions take an operand representing true or false that is com- global state visible to every block. The temporary operands pared against the polarity encoded into the predicated in- however are only visible within the block they are defined. struction (denoted by _t and _f). The test instruction in line The only instructions that can read from the global register 45 creates a predicate that the receiving instructions (lines file are register READ instructions (lines 19-27). However, 46-47) compare against their own encoded predicate. Only most instructions can write to the global register file. instructions with matching predicates execute. CYCLE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 enough power/performance gains over current static multi- FETCH IF IF IF IF core architectures to justify a transition to a new ISA. READ R R R R R E2’s performance and power efficiency are built on its READ R R R R ability to compose and decompose cores dynamically, so MEM L L L S the correct policies and mechanisms for managing dynamic EX A A A M M M M M M M M M A A B composition will require careful consideration. Ideally we EX M A T M M M M M M M M M A A A would like to leave all decisions about composition to the EX M M M M M M M M M A A runtime system, freeing the programmer completely from EX M M M M M M M M M A A reasoning about the underlying hardware. Finally, there is a wide variety of application domains where Figure 3: One possible schedule for Figure 2. E2’s ability to trade-off power and performance could be useful, ranging from embedded devices to the data center. In the months ahead we plan to examine a diverse set of work- Blocks are limited to a maximum of 128 scalar instruc- loads and investigate how broadly an E2 processor can span tions. When using vector instructions blocks are limited to the power-performance spectrum. a total of 32 scalar and vector instructions. Block _rgb2y contains a mix of 27 scalar and vector instructions. 6. REFERENCES [1] Microsoft Phoenix. 4.3 Instruction Schedule http://research.microsoft.com/phoenix/. Figure 3 gives one possible schedule for the example in [2] ARM. Cortex-A9 MPCore technical reference Figure 2. We assume a three cycle 32-bit floating point mul- manual, November 2009. tiply, and that all loads hit in the L1 cache and require three [3] D. Burger, S. W. Keckler, K. S. McKinley, M. Dahlin, cycles. The architecture is capable of fetching eight instruc- L. K. John, C. Lin, C. R. Moore, J. Burrill, R. G. tions per cycle and thus requires four cycles to fetch the 27 McDonald, W. Yoder, and the TRIPS Team. Scaling to instruction block. In cycle one, eight register read instruc- the End of Silicon with EDGE architectures. IEEE tions are fetched which are all available for execution in the Computer, 37(7):44–55, July 2004. following cycle since they have no dependencies. Two reg- [4] Cadence. Cadence InCyte Chip Estimator, September ister reads can execute per cycle requiring five cycles to read 2009. all the global registers. In cycle two, registers R4 (line 20) [5] H. Esmaeilzadeh and D. Burger. Hierarchical control and R8 (line 24) are read and the resulting data is sent to the prediction: Support for aggressive predication. In vector load (line 30), multiply immediate (line 40), and add Proceedings of the 2009 Workshop on Parallel immediate (line 48) instructions. Since each of these instruc- Execution of Sequential Programs on Multi-core tions is waiting on a single operand, they are now all ready Architectures, 2009. and begin executing in cycle three. Execution continues in [6] M. D. Hill and M. R. Marty. Amdahl’s law in the this dataflow fashion until the block is ready to commit in multicore era. IEEE COMPUTER, 2008. cycle 17. [7] E. Ipek,˙ M. Kırman, N. Kırman, and J. F. Martínez. Core Fusion: Accommodating software diversity in 5. CONCLUSION chip multiprocessors. In International Symposium on In this paper we described the E2 architecture – a new Computer Architecture (ISCA), San Diego, CA, June dynamic multicore utilizing an Explicit Data Graph Exe- 2007. cution (EDGE) ISA, designed to achieve high performance [8] N. P. Jouppi. Improving direct-mapped cache power efficiently. As an EDGE architecture, E2 efficiently performance by the addition of a small exploits instruction-level parallelism through dataflow exe- fully-associative cache and prefetch buffers. cution and aggressive speculation. In addition, we have de- SIGARCH Computer Architecture News, 18(3a), 1990. scribed how the architecture adapts to handle data-level par- [9] C. Kim, S. Sethumadhavan, D. Gulati, D. Burger, allelism through vector and SIMD support. This vector sup- M. Govindan, N. Ranganathan, and S. Keckler. port can be interspersed with scalar instructions, making E2 Composable lightweight processors. In Proceedings of more flexible than traditional vector processors, and more the 40th Annual IEEE/ACM International Symposium capable than traditional scalar architectures. on Microarchitecture, 2007. We have developed an architectural simulator for E2 using [10] S. Sethumadhavan, F. Roesner, J. S. Emer, D. Burger, SystemC and a new compiler backend with the Microsoft and S. W. Keckler. Late-binding: enabling unordered Phoenix software optimization and analysis framework [1]. load-store queues. In Proceedings of the 34th Annual We are currently developing a cycle accurate FPGA imple- International Symposium on Computer Architecture, mentation that when combined with our industrial strength pages 347–357, New York, NY, USA, 2007. ACM. compiler, will allow us to perform a detailed exploration and [11] T. Sherwood, S. Sair, and B. Calder. Predictor-directed evaluation of the architecture. stream buffers. In Proceedings of the 33rd Annual Many challenges lay ahead. To be compelling as an accel- ACM/IEEE International Symposium on erator, we must demonstrate that E2 provides better perfor- Microarchitecture, 2000. mance, power efficiency, and programmability than special- [12] A. Smith. Explicit Data Graph Compilation. PhD ized accelerators such as GPUs and dedicated vector pro- thesis, The University of Texas at Austin, 2009. cessors. E2 may also excel as a general-purpose proces- sor, in which case we must show that it provides compelling