Of course, this will lead to a logical end: for the same type of architecture the performance of 64bit processors will be higher only for those tasks, which use 64bit calculations, because they will no longer need to resort to any tricks like the use of extra registers (see the previous passage). 32bit applications will be effected as fast as they used to be effected with 32bit processors, although they might be able to access 64bit address space after some additional individual changes. Certainly, if the time and effort spent on that is really worth it.

We mentioned not for nothing that our statement is valid only “for the same type of architecture”. Speaking about x86, it will work only for Athlon 64 and Opteron from AMD. All other players took a completely different direction developing totally new architectures for 64bit technology. Take Intel, for instance, which was the one to start the whole stir around 64bt processors, actually.

The company preferred to carry out the so-called “velvet” revolution: they kept the 32bit processor generation on the market and started introducing 64bit family little by little. The move from 16bit to 32bit was absolutely discreet: i386 completely replaced i286. Now the situation is different.

They developed the CPU from the very beginning in two versions at a time: by Intel engineers and by Hewlett-Packard engineers. In fact, both developed chips were based on the same ideas, because they were developed by both teams together and were intended to give birth to one and the same family of future processors. Of course, the general EPIC (Explicitly Parallel Instruction Computing) ideology, which came to replace CISC, and IA-64 architecture including instructions, registers description and so on, were a sort of uniting power in this case. However, architecture is usually subject to changes: remember the differences between 8086 and i486 CSC processors based on the same x86 architecture?

Just like Merced and McKinley, Itanium and Itanium 2 are both based on the same ideology, but on different types of architecture. Something like that has already happened once: we are talking about Pentium and Pentium Pro. However, they did have some common traits, and the today’s newcomers also have something in common, this is what EPIC is here for. First of all we are talking about fully-fledged large-scale super-scalarity, i.e. the ability to perform several instructions at a time. This is where the CPU needs execution modules: for integer operations, for floating-point operations, etc.

Unlike Pentium and its successors, working with the code themselves, EPIC-processors rely on the compiler, which should analyze the code and find the most optimal spots where its processing could be parallelized. This info is then submitted to the CPU. This is why these CPUs are called “explicitly parallel”. In fact, it is a very convenient thing: the CPU doesn’t have to decide anything, the compiler is the one to explain everything to the CPU. Besides, all execution units of the processor should be evenly loaded, that is why the new processors boast powerful branch prediction algorithms, preliminary code processing, data prefetch, etc.