Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
On Wikipedia I have read the i860 from 1989 memory bus was at least 64bits wide.
(It is the first CPU the Windows NT kernel was running on.)
I think even 10 years later (1999) most desktop CPUs were 32 bit.
So why was that?
Edit: I mean the address bus. Was it necessary to address more than 4GiB? On Wikipedia they say all buses were 64bit.
The i860, like any CPU, has a number of buses. The main ones worth considering here are the data buses, between memory and the caches, and caches and the execution units, and the address bus, which is the one that matters for your edited question. The i860 also has separate caches for instructions and data, which is significant for the buses.
In general, a 64-bit data bus (which doesn’t imply that the CPU itself is a “64-bit CPU”) allows faster access to memory, or anything else on the bus, than a 32-bit bus (which would be the basic size for a 32-bit CPU’s data bus), by allowing more data to be transmitted in one transaction. This is the main benefit of the 64-bit bus between memory and the CPU as a whole in the i860.
For the i860 specifically, the 64-bit bus between the instruction cache and the execution unit allows loading 64 bits at a time, which is useful for the i860’s “dual instruction mode”. Two instructions are loaded in parallel, one “core” instruction and one “floating-point/graphics” instruction. Both instructions could then run in parallel if all the data they needed was already in the cache. The i860 was a VLIW CPU with a fixed 32-bit instruction size, so two instructions would always take exactly 64 bits.
The internal bus to the data cache is wider still, 128 bits wide; this allows loading 128-bit values in a single transaction (fld.q) from the cache. The i860 also supports “pipelined” floating-point loads which bypass the cache; the 64-bit external data bus results in a maximum per-instruction load of 64 bits (pfld.d).
It didn’t take ten years for desktop CPUs to have 64-bit data buses: the Intel Pentium, released in 1993, used a 64-bit data bus.
The i860 used a 32-bit address bus, its physical address space was limited to 4GiB. See section 4 of the i860 Programmer’s Reference.
It has something to do with the cache structure. Without a cache, every bus access is a "raw" load/store operation and if most of the load/store operations are narrower than 32 bit, there's little benefit of a wider bus.
However if the processor has a internal cache, then memory would be accessed one cache-line a time, regardless of load/store instructions. A cache-line is usually 128-bit wide at least and can fully fill a 64-bit bus.
32 bit virtual address space was a bit of a bad idea.
Intel basically goofed by making the address space on i386 32-bits wide. This required, in practice, for every process to use a dedicated virtual-to-physical address map, and for the caches to be using physical memory addressing. This meant that the expensive address translation was on the critical path to the caches: all addresses had to be translated before hitting the cache. This was - and still is - extremely die-space and power hungry. Fast logic means high power use.
If Intel had the foresight to use 64-bit virtual address space, perhaps limited to say 30 bits on i386 as an implementation limitation, but later expanded, then the caches could have used virtual addressing. This would move address translation to the bottom, just before hitting DRAM. Since DRAM access is relatively slow, the address translation overhead would have been negligible, and could have been implemented using slower logic, and more of it - to accommodate larger translation tables at the same cost in power and die area.
The 32-bit per-process address space of x86 had a rather big performance impact in terms of achievable clock speeds, power envelope, process switching overhead, complexity of parts of OS kernel, etc. Having the architecture deal with 64-bit virtual addresses internally, and only needing to check protection buffers on cache accesses, vs. doing address translation, would have probably avoided the fiasco known as Netburst deeply-pipelined architecture of P4.
Of course, back when the 386 was first introduced, there was no need for more than 32 bits of external address bus, and the 386sx has just 24 external address bits. But the fact that the virtual address space was just 32 bits, and caches had to use physical addresses, turned out to have consequences that last until this day, and result in higher power use, higher R&D costs of CPU development, and so on.
