October 2, 2001:  AMD's  Hammer micro architecture preview 

 

number:	model	date filed:	AMD's  Hammer  patents
6,266,763	K8-2	Jan, 5 '99	Physical rename register for efficiently storing floating point, integer, condition code, and multimedia values
6,256,721	K8-1	Jun, 16 '00	Register renaming in which moves are accomplished by swapping tags
6,247,106	K8-2	Jul, 27 '00	Processor configured to map logical register numbers to physical register numbers using virtual register numbers
6,240,503	K8-1	Nov,12'98	Cumulative lookahead to eliminate chained dependencies
6,230,262	K8-2	Jul, 31'98	Processor configured to selectively free physical registers upon retirement of instructions
6,219,784	K8-1a	Nov,16'98	Processor with N adders for parallel address calculation
6,212,623	K8-2	Aug,24'98	Universal dependency vector/queue entry
6,212,622	K8-2	Aug,24'98	Mechanism for load block on store address generation
6,199,154	K8-1a	Jun,19'98	Selecting cache to fetch in multi-level cache system based on fetch address source and pre-fetching additional data to the cache for future access
6,167,506	K8-1a	Apr,23'98	Replacing displacement in control transfer instruction with encoding indicative of target address, including offset and target cache line location
6,141,747	K8-2	Sep,22'98	System for store to load forwarding of individual bytes from separate store buffer entries to form a single load word
6,134,649	K8-1a	Apr,23'98	Control transfer indication in predecode which identifies control transfer instruction and an alternate feature of an instruction
6,122,727	K8-2	Aug,24'98	Symmetrical instructions queue for high clock frequency scheduling
6,122,656	K8-2	Jul,31'98	Processor configured to map logical register numbers to physical register numbers using virtual register numbers
6,119,223	K8-2	Jul,31'98	Map unit having rapid misprediction recovery
6,112,293	K8-1a	Jul,14'98	Processor configured to generate lookahead results from operand collapse unit and for inhibiting receipt/execution of the first instruction based on the lookahead result

The Hammer   The Hammer diagram above shows a very wide super-scalar processor. Innovative new units like the "ESP Look Ahead unit" and the  "Forward Collapse unit" should help to extract an unprecedented level of instruction level parallelism from the good old X86 instruction architecture to feed all the hungry functional units. The pipeline supports not less then six instructions in parallel, twice as much as the current Athlon. It contains a double core. Both cores are loaded with functional units to execute the instructions.  Some might argue that the amount of Instruction Level Parallelism in X86 code is limited and that wide super-scalar, highly pipelined architectures can not increase the performance anymore. The extra functional units simply hang in there idle. These arguments are based on theoretical studies that count the ILP in a wide range of programs.  The Hammer may want to prove otherwise. The theoretical studies for instance consider the processor cycle and the operations as "atomic": The smallest possible units. The hardware designer however works with Gates and Gate-delays, significantly smaller units. Some dependent instructions might start only one or two gate delays after each other, meaning that they all may be executed in the same cycle with the right hardware, effectively in parallel.... This is for instance the case in the ESP Look Ahead Unit that allows among other things that consecutive PUSHes and POPs to and  from the stack can be executed simultaneously!  Furthermore, a processor may increase IPL by collecting some statistical information during run time and apply this to increase ILP. This is how the Forward Collapse Unit together with the Branch Predictor can increase ILP by effectively removing up to 2 conditional branches per cycle from the instruction stream.  Most innovations in the Hammer are intended to make it the X86 processor with the highest Instruction Level Parallelism yet and should make it a very powerful single thread processor.  There is no explicit talk of SMT (Simultaneous Multi Threading) in any of the patents. A processor like this one "screams" however for an SMT inplementation. SMT gives chip-architects the ideal excuse to continue on the line of wider and wider super scalar processors and higher and higher super pipelined processors, beyond the level that would be economically feasible for single thread processors. Further on we do a bit more SMT speculation of our own.  below we discuss the various stages of the micro architecture shown in the diagram Instruction fetch and scanning Instruction queuing and aligning rename and schedule unit the Dual Cores Chip-Sets and Multi Processing   HOME

 

AMD's Hammer Micro Architecture:  Instruction fetch & scanning   Two levels of instruction cache.  The single cycle latency Level 0 cache can provide up to four cache lines each cycle while the large multi-cycle Level 1 cache provides one line just as it does in the Athlon. The Level 0 cache serves two purposes: It allows the  Level 1 instruction cache to grow because it can compensate the higher latency in many cases. It also allows the branch prediction unit and the branch history table to grow: Branch prediction: "going both ways before deciding on the prediction" The Level 0 cache simultaneously provides the code that has to executed when a conditional branch is taken as well as the code that has to be executed if the branch is not taken. The processor goes "both ways" for a moment until the large branch prediction unit has had the time to make a decent decision. In some cases the result of the branch prediction is effectuated several cycles after the instructions are loaded from the level 0 cache:  The "forward collapse unit" that is some 3 stages further down the line handles short forward branches where the branch and the destination address in the same "run" of code. The instructions that are skipped if the branch is taken are marked as canceled in this stage. The "forward collapse unit" can handle up to two short forward branches per cycle to handle these nested "if-then-else-statements" which are usually responsible for this type of code. Increasing Instruction Level Parallelism by "removing" conditional branches. The effect is that more instructions per cycle can be handled. Branches typically reduce ILP (instruction Level Parallelism) because subsequent instructions depend on the outcome of the condition. The Hammer should be able to extract more ILP from the instruction stream then any compiler would be able to find.  Actually more then the theoretical maximum that a compiler would be able to extract. The difference is that a compiler can only remove conditional branches from the code when it can predict them with 100% accuracy. Units like the "forward collapse unit" can "remove" up to 2 conditional branches per cycle from the instruction stream in cooperation with the branch predictor that also can predict up to 2 conditional branches per cycle!         Branch prediction:  "remembering instead of re-learning"  A huge 64k entry branch history table is used for branch prediction. The "taken/not taken" results of the 16 latest conditional branches are used to calculate an index in the 64k table. The table contains 65536  2 bit bimodal counters that hold the predictions:   0 strongly not taken,   1: weakly not taken,   2 weakly taken,   3: strongly taken.  Such a large table can store the characteristic branch patterns of many different branches in a larger program without much interference. A smaller table has to re-learn the branch pattern again when it comes back to recently executed code. A very large table still holds valid information even when the processor has been executing other code for a while. And a  larger table can also be more accurate then a smaller one. Up to two branches may be predicted per cycle. Instruction pre-decoding:  Support for handling branches  Each byte in the instruction caches has 2 bit of pre-decode information. AMD has looked at many different ways of pre-decoding sometimes with much more then two bits. The final scheme chosen is shown in the table below.  - definition of the pre-decoding bits - bit 1 bit 0 instruction byte description 1 0 -----------   start byte of non-branch instruction 1 1 -----------   start byte of  branch instruction 0 0 00-aaaaaa   relative branch to byte aaaaaa of current cache line 0 0 01-aaaaaa   relative branch to byte aaaaaa of first cache line above 0 0 10-aaaaaa   relative branch to byte aaaaaa of second cache line above 0 1 01-aaaaaa   relative branch to byte aaaaaa of first cache line below 0 1 10-aaaaaa   relative branch to byte aaaaaa of second cache line below Pre-decode bit 1 identifies the byte as the Start byte of an instruction. The instruction can then either be a branch or a non branch instruction depending on pre-decode bit 0.  It is important to identify branches early to get the Pre-fetch unit to load new instructions as soon as possible. A second innovation are the pre-computed branch addresses of 8 bit and 32 bit relative displacements. The instruction cache does not contain the displacements anymore but the absolute addresses instead. The address calculations are done only once when the instructions are loaded in the instruction cache instead of each time the instruction is executed.

 

AMD's Hammer micro architecture: Instruction queuing & aligning   The Instruction Queue: Delivering  up to six instructions per cycle The instruction queue receive runs of instruction byte including those bytes that have been marked as cancelled by the forward collapse unit because they are predicted to be skipped over by short forward branches. The instruction queue select up to six instructions cycle within up to four runs of instructions and present them to the alignment unit, skipping the cancelled instructions.  The Alignment unit: The alignment unit is configured to route the instructions bytes belonging to the up to six instructions selected by the instruction queue to an equivalent number of issue positions from where they will be fully decoded.