- Oh, yes it actually is!
What makes something a 64-bit processor anyway? ALU width? GP Register
width? Pointer width? Virtual address space size? Physical address space?
Of the above? - "Virtual address space size" comes closest. Though
that is something the OS decides. Windows64 'only' gives us 4
Terabytes, while 64 bits are potentially good for 16 Exobytes.
There's no cloudy mystery about 64-bitness.
Bits can of course be used to refer to the length of many various
things.
But when it comes to 16-32-64 bit processors there's no doubt about
what it refers to.
- It's the length of the native machine code instructions
addressfield.
It's this property that confers the capability of the cpu. It's that
simple.
Or hard, which is why a 32-bit cpu can never become a 64-bit. Nor even
be able to 'emulate' a 64-bit. You have to feature a complete new set
of 64-bit instructions, and a complete new memory management.
That exactly means an entirely new cpu family from the ground up.
I've heard it said elsewhere here that the original 68000 used a 16-bit ALU,
and yet it had a 32-bit instruction set and address space (albeit with 24
external lines). Was it a 16 bit CPU, a 32 bit CPU, or a 24 bit one?
- 32-bit! - And no doubt about it at all!
16 bit ALU was only a transistor count and performance decision. Later
68k members got 32-bit ALU. Not that it means anything, other than
using more available transistors for better efficiency.
Today, with our piped, cached and branchpredicted cpus, we would talk
about the depth and width, in terms of pipes, of the execution unit.
It still remains the question of how many transistors are going to be
used for a diminishing return in performance.
The 68000 featured 32-bit registers, and used 32-bit addressing
instructions. And it's the latter part that makes it a true, bona fide
32-bit cpu. As all 68k family members.
It could also use half registers as 16-bit registers, and indexed
16-bit addressing. In those days, 16-bit integers and short pointers
weren't obscene.
It also used a 16-bit external databus and a 24-bit external
addressbus. Again, other 68k members employed anything from 8-bit to
64 bit buses, most of them featuring 32-bit. That happen to be just as
irrelevant for their 32-bitness as the fact that the '386SX (another
32-bit cpu) also used 16-bit databus. That the '286 (a 16-bit cpu)
used 24-bit addressbus. That the 8086 (a 16-bit cpu) had 20 bit
addressbus. That the 8088 (16-bit) featured 8-bit databus. That the
Pentiums (32-bit cpus) have 36-bit physical addressing and 64-bit
databus. That the AthlonFX (64-bit) feature 128-bit databus and
registers, and 40-bit addressbus. Etc ad nauseum.
The integer registers should be least as wide as instruction address.
And existing registers cannot shrink. Nor can any previously existing
instruction use the extension of widened registers or any additional
registers.
Apart from that, these physical 'width'-thingys are all minor
architectual concerns. Something that can easily be changed on the
next member of the family (as is usually also the case), without
anyone really noticing. It's just a matter of economy and what can be
made effective use of.
The instructions address length, on the other hand, is fundamental. It
means different instruction sets and memoryhandling == completely
different cpu == completely different OS == completely different
software == completely different capabilities.
32-bit backwards compatibility is something that has to be
painstakingly designed into the cpu as an additional feature.
Just as the '386 did with 16-bit compatibility.
Still, expect a massive smokescreen about 'bits' from Intel and
affiliated journalists. They've already started.
ancra
)