Does it refer to the size of the external data bus, the address bus, or the registers? Do all three have to at least be 32-bits wide for the CPU to be called a 32-bit CPU, or, does just one have to be 32-bits wide?
Printable View
Does it refer to the size of the external data bus, the address bus, or the registers? Do all three have to at least be 32-bits wide for the CPU to be called a 32-bit CPU, or, does just one have to be 32-bits wide?
It can be any of those or some combination.
Generally when you hear "32bit" they are referring to the size of the CPU's general purpose registers, which is usually also the size of the data buss... That's not merely a coincedence, it's so that data can be fetched from memory in a sensible manner... A system with 32 bit registers and an 8 bit data buss would be horridly inefficient as it would take 4 memory fetches to get a single 32 bit value, so the smart money is on having the registers and external data buss the same size.
The address buss can be any width the engineers decide, although it is generally in multiples of 8 bits. A 32bit cpu with a 128bit address buss is entirely doable... as is a 32 bit cpu with a 16 bit data buss (although the latter would be kind of silly since it could only access 64k of memory).
You will also hear the "32bit" reference used with compilers (for various languages)... in this case referring to the size of an "integer" value in the code... Again, the smart money is on matching the CPU's register sizes.
Quite often you will hear people here (including me) chiding people with ancient compilers to update to a more modern one... this is generally because these older compilers (turbo c++ being the worst offender) actually work on 16bit integers that come from the days of 16 bit processors such as the 8086 and iapx286... These old 16 bit compilers are woefully inadequate in today's world of 64 bit CPUs...
I don't think that is the case.Quote:
Originally Posted by CommonTater
32-bit software simply means it's designed to run on a 32-bit CPU.
16-bit software means it's designed to run on a 16-bit CPU.
As you can imagine, 32-bit cpus and operating systems are generally backwards compatible. The same is true for 64-bit.
That's true -- using 16-bit software is one thing, but I can't imagine wanting to write a new 16-bit program for a 32-bit or 64-bit CPU as the target. That's how it is inadequate.
Exactly...Quote:
Originally Posted by whiteflags
It won't be long until our present 32bit compilers are getting the same screech...
It also has implications on the size of the address bus. 16bit means you can address 2^16 bytes of memory(although segmentation allows for a total of 2^20 bytes), 32bit means you can address 2^32 bytes of memory, and 64bit means you can address 2^64 bytes(though only 2^48 bytes of physical memory can be directly referenced on the AMD64 arch because AMD thought 2^64 of memory is insanely excessive.)
That's alright. We can still access up to ~250ish billion bytes, that is ~250 TB of memory.
Although the idea of ~10ish exabytes of memory sounds kindof nice.
You'd have to have ~4166666666 times more money than Bill Gates to buy all that RAM. :p
Oh, but I still have 50 years to buy all that ram, don't I? :p
Well, that's the thing... Win7 X64 no longer supports 8 or 16bit applications.Quote:
Originally Posted by Elysia
Not an easy answer to give to the OP, if you think about it:
We can pretty much exclude the address bus, since historically not always it has matched the data bus. We should probably also exclude the general purpose registers since some architectures offered coupled registers along with instructions (the so-called 8-bit Z80, for instance, offers coupled 8-bit registers and can perform 16-bit arithmetic and addressing). We should finally also exclude data buses since these have been having varied sizes, not always conforming with the term being used.
What makes an architecture 8-bit, 16 or 32, seems sometimes what someone decided to call it and nothing much more. The new 32/64 processors are essentially a proof of this concept, when you consider that even an operating system might have a saying on what type of machine you will be running. And if I'm currently writing this on a 32-bit i5 simply because I installed the x86 version of windows here, what's there to say that the 8-bit Z80 was after all a 16-bit processor because I could write 16-bit instruction for it?
For what it's worth Mario... it's usually the GP accumulator that determines the stated bit width... it was 8 bits (AX) in the z80, now usually 64bits (EAX) in the newer machines.
There is a relatinship to hardware...
General purpose registers are usually the same width as the data bus, but address bus varies quite a bit.
8051, an 8-bit architecture, has both 8-bit address bus and 16-bit address bus (in different addressing spaces). This is the case for many 8-bit architectures, because 256 bytes are just not enough.
Anything higher than 8-bit, though, address bus is usually the same width as data bus. There are some exceptions. For example they tried to hack the x86's 32-bit addressing bus to support more than 4GB RAM, but the "natural" addressing space is still 32-bit.
x86-64 is kind of odd. I tend to think of it as a CPU that supports 2 architectures. It has a 32-bit mode where everything (GP, data and addressing buses) is 32-bit, and a 64-bit mode where everything is 64-bit.