![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
EPIC: the solution
The new architecture had to largely solve these problems, in addition to that it had to be able to last about 25 years and the scalability had to be good. Because of this it was soon decided that the new standard had to be based on EPIC: Explicitly Parallel Instruction set Computing. The ideas behind this originated around 1980 and are centered round executing instructions in parallel and optimizing efficiency in the use of the available execution units. An EPIC architecture is therefore ideal to solve the previously described problems.
It's impossible for a processor to know what instructions influence each other. The compiler, the program that translates programming languages into machine code, however has plenty of time. The E in EPIC stands for Explicit and this means that the program tells the processor which parts can be executed at the same time (in parallel). An EPIC compiler therefore has more responsibilities than an x86 compiler. It's his task to analyze the program code, determine where branches occur and find out what parts can be executed in parallel.
The compiler can't make sure that there will be a continuous stream of code to be processed so EPIC processors will be troubled by branches too. EPIC solves this by means of predication. The processor does not bet on one possibility but processes both possibilities at the same time, as soon as becomes known which one is the right one the other one gets killed. Suppose the result of A determines if instruction B or E should be executed. Instead of betting A, B, C, D, E, F and G are entered into the pipeline. As soon as A comes out it becomes clear that it E was the right answer. At this moment the execution of B, C and D is aborted and the values resulting from E, F and G are entered in the correct places. Had B, C and D been the right ones then this would not have cost any extra clocktick. The enormous penalty of miss-prediction is eliminated this way.
It can also happen that it is temporarily not possible to execute instructions because data from the cache, The RAM or, worst case, the hard disk are necessary. EPIC tries to minimize the wait by means of speculation. This means that the processor is told that he'll be needing certain data soon before he actually needs them, the cpu can then order them to be fetched and put in the cache. A disadvantage of getting these data early is that things can change during the period between getting them and actually using them, that's why the processor will check once more right before executing the instruction.
The end result that comes out of the compiler are instruction bundles in which there are a number of instructions that have previously been checked on the possibility of parallel execution without influencing each other. Apart from that there is some information in there for the processor about the instructions in the bundle and the relations to the previous and next bundle, because bundles are grouped too by the compiler. There can also be additional instructions in a bundle, for instance for speculation. This is a totally different approach than x86 and is best compared to the VLIW (Very Long Instruction Word) as used by Transmeta.
It's impossible for a processor to know what instructions influence each other. The compiler, the program that translates programming languages into machine code, however has plenty of time. The E in EPIC stands for Explicit and this means that the program tells the processor which parts can be executed at the same time (in parallel). An EPIC compiler therefore has more responsibilities than an x86 compiler. It's his task to analyze the program code, determine where branches occur and find out what parts can be executed in parallel.
 |
The compiler can't make sure that there will be a continuous stream of code to be processed so EPIC processors will be troubled by branches too. EPIC solves this by means of predication. The processor does not bet on one possibility but processes both possibilities at the same time, as soon as becomes known which one is the right one the other one gets killed. Suppose the result of A determines if instruction B or E should be executed. Instead of betting A, B, C, D, E, F and G are entered into the pipeline. As soon as A comes out it becomes clear that it E was the right answer. At this moment the execution of B, C and D is aborted and the values resulting from E, F and G are entered in the correct places. Had B, C and D been the right ones then this would not have cost any extra clocktick. The enormous penalty of miss-prediction is eliminated this way.
 |
It can also happen that it is temporarily not possible to execute instructions because data from the cache, The RAM or, worst case, the hard disk are necessary. EPIC tries to minimize the wait by means of speculation. This means that the processor is told that he'll be needing certain data soon before he actually needs them, the cpu can then order them to be fetched and put in the cache. A disadvantage of getting these data early is that things can change during the period between getting them and actually using them, that's why the processor will check once more right before executing the instruction.
The end result that comes out of the compiler are instruction bundles in which there are a number of instructions that have previously been checked on the possibility of parallel execution without influencing each other. Apart from that there is some information in there for the processor about the instructions in the bundle and the relations to the previous and next bundle, because bundles are grouped too by the compiler. There can also be additional instructions in a bundle, for instance for speculation. This is a totally different approach than x86 and is best compared to the VLIW (Very Long Instruction Word) as used by Transmeta.
Next page (Intels Tahoe architecture - 4/10)
