Since AMD launched its Opteron processor and its Athlon64 it has been almost 20 years, but the transition from 32-bit to 64-bit in x86 has not completely finished, especially due to the fact that there are a lot of software that does not work on 64 bits. Is it time to ditch 32-bit on x86 and force the transition and why?
For many, maintaining backwards compatibility with 32 bits is still an anecdote that does not affect the performance of their PCs, however maintaining said compatibility also means maintaining the way in which each and every one of the 64-bit instructions work with the same performance as 32-bit when sharing the data path.
Both Intel and AMD can consider a renovation of their 64-bit architecture, compatible with all software but with a much higher performance by doing a complete renovation of the way in which they internally process each of the x86 64-bit instructions.
But what is a 64-bit architecture? A 32-bit architecture is considered to be any one that can address and therefore access up to 2 32 bytes of RAM or what is the same: 4 GB of RAM, while a 64-bit processor can see up to 2 64 bytes of RAM and therefore can address a much larger amount of memory directly.
Little by little we see how the standard capacity of the computers that are for sale exceed the figure of 4 GB of RAM, this means that they can run the 64-bit versions of the programs that are increasing. Since the life of a computer is not more than five years, it will reach the point where each and every PC on the market will be able to run the 64-bit versions of the programs.
That is why the duality between 32-bit and 64-bit in terms of applications should disappear at a point to leave 32-bit applications in the trash of history forever.
The origin of 32 bits in x86 CPUs
The x86 architecture is originally a 16-bit architecture that started with the 8086/8088 series. The first time that Intel implemented a 32-bit version of the architecture was in the 80386. Intel made a very ingenious design decision regarding the registers of its processor: instead of creating new registers for the 32-bit mode they extended 16-bit ones, something that AMD later repeated when developing the 64-bit extension of the architecture.
The idea of using extended versions of registers instead of new registers is a way that Intel had of not having to duplicate the data paths of each instruction on the one hand and on the other hand of not making the instructions of the original set incompatible. This ensured that 16-bit x86 compiled programs would work on later processors.
From the 80386 to the Intel Pentium the data path of each instruction during the fetch and decode stages was the same, but Intel from Pentium Pro onwards decided to re-make the data paths of all 32-bit instructions to optimize its operation to the detriment of the 16 bits.
The Pentium Pro, a historic precursor to change
In the Pentium Pro, Intel decided to completely renew the entire instruction cycle of the entire set of 32-bit instructions from the Pentium Pro, an improvement that I do not apply on the 16-bit instructions in such a way that the 16-bit programs to MS-DOS or Windows 3.1 did not work better than on an Intel Pentium, so to get the maximum benefit from that processor it was necessary to use 32-bit applications.
To the Pentium Pro MMX instructions were added and it became the Pentium II, it was at that time that the developers of both applications and operating systems were very clear that it was time to abandon 16 bits once and for all. Which ended with the 2001 release of Windows XP. the first Windows for desktop with NT base, at that time no one thought to develop 16-bit applications anymore.
In the case of a reform of the same type coming from the hand of Intel and / or AMD, they can be used to redo the data paths of each of the instructions. The consequences are that 32-bit applications would not run as quickly as 64-bit applications, but there would be no reason to stay in 32-bit for anyone, since the advantages that the full jump to 64-bit would bring would be a lot greater.
The abandonment of 32 bits in PC are key to the standardization of the SSD
First of all, we have to understand that unlike hard drives, the NAND Flash memory used in SSDs can be addressed as if it were RAM. It is not to be confused with the fact that the content can be accessed directly, since the SSD is lower in the hierarchy. But the high speed of the PCI Express interface allows data to be copied very quickly and almost transparently to a part of the RAM that would be used as cache.
Until now, when using large files, the hard disk was used, which has a much lower access speed and enormous latency, apart from an enormous search time. When a hard disk is accessed, the way to access it is not within the RAM memory address, but by using virtual memory and a slower and more complex access mechanism
On the other hand, SSD disks allow direct addressing from the program as if it were part of the RAM memory, which is the benefit of having a huge addressing. But for this it is better to talk about specific examples at the software level.
The advantage is that 32-bit x86 applications cannot have immediate access to more than 4 GB of RAM, even if the addressing were only 48 bits, we would be talking about 256 TB of memory accessible directly. Imagine for a moment that you are working with a 4K video in a program with Sony Vegas where the master has a size of several tens of gigabytes and imagine being able to control the timeline with all the ease in the world.
Another example would be in a huge database, imagine that you are working on an application that has to do continuous searches of the database at full speed, taking advantage of the enormous speed that the SSD memory allows in addressing. In reality there are many possibilities, especially in applications that make use of large volumes of data.
At the operating system level, and to finish, it must be taken into account that many applications use system libraries, the fact of having the entire operating system in the address of the processor greatly accelerates the operation of each and every one of the applications.