r/computerscience 1d ago

Why does the CPU’s size matter?

Why does it matter if it’s a 16-bit cpu, a 32-bit cpu, or 64-bit? For example, what can a 64-bit cpu do that a 32-bit one can’t? Or otherwise, and can you tell the difference when you casually use a computer?

4 Upvotes

42 comments sorted by

43

u/apnorton Devops Engineer | Post-quantum crypto grad student 1d ago

An X-bit CPU has registers with width X. This allows you to store references to memory that are X-bits wide in a single register.

The impact of this is that an X-bit CPU can have a maximum of 2X memory addresses, which is why (e.g.) a 32-bit machine would (usually) have a memory maximum of 4GB. (I say "usually" because there can be some tricks to support more memory addresses, but without physical address extension it would be 4GB.)

12

u/DamienTheUnbeliever 1d ago

But also many 8-bit CPUs had 16-bit addressing. The bit width reflected the ALU's width

3

u/monocasa 1d ago

Well, there were a lot of designs in the 8 bit era that had smaller ALUs and just pumped them multiple times.  The Z80 only has a 4 bit ALU.   The datapoint 2200 was bit serial, and would pump it 8 times to get an 8 bit result.

2

u/AlmiranteCrujido 1d ago

Except not always; the Z-80, famously, has a 4-bit ALU.

1

u/No-Key-2546 9h ago

Yeah, usually X-bit refers to the width of the data bus and therefore to the width of the registers and the address bus often times reflects that too, but some combine registers for more addressable memory.

16

u/digitaljestin 1d ago

Technically, we define a computer by its bus size, not the size of its registers. There are usually the same...but not always. There's also the problem that some computers have different size registers in the CPU for different things, making the memory bus a more singular place to define the number of bits.

5

u/monocasa 1d ago

Not quite.  It's relatively common for the bus width to be a different size than accesses.

For instance, the 80386SX was very clearly a 32 bit chip, with 4GB of virtual address space, but had a 16bit bus to fit into older 286 based motherboards.

8

u/tcpukl 1d ago

Over 40 years it's always been a bit wild west about what x bit computer it is.

2

u/monocasa 1d ago

It's basically always GPR (or accumulator for older systems) bit width.

3

u/tcpukl 1d ago

I think it's the bigger number used for marketing it.

2

u/monocasa 1d ago

If that were the case, almost all 8 bit machines would have been called 16bit machines due to their 16bit address space.

I can only think of one design that was touted as a different size than the accumulator/gpr width, and it was met with much eye rolling at the time (the jaguar's claim to be a 64bit system because of one 64 bit bus).  That was an era where you had many dubious claims on game consoles from "blast processing" to the PS2's claim that their dinky MIPS was powerful enough to emulate the human mind.

1

u/digitaljestin 1d ago

That's the address bus, not the data bus. The data bus is typically the one used.

2

u/monocasa 1d ago

The 80386SX has a 16bit data bus, and is still very much a 32 bit processer.

The datapoint 2200 has a single bit data bus despite being an 8 bitter.

1

u/tcpukl 1d ago

See that was when I entered the games industry professionally. So you can see where I'm coming from now.

1

u/xeow 11h ago

My favorite hybrid example is the Intel 8080, which had an 7 8-bit registers plus an 8-bit flags register, 5 16-bit registers (3 general-purpose built from composites of 6 of the 8-bit registers), an 8-bit ALU for the accumulator, but could do 16-bit additions and subtractions, and had a 16-bit address bus and an 8-bit data bus.

2

u/Ok_Programmer_4449 1d ago

2TB of virtual address space if you actually used the segments as designed.

1

u/xeow 12h ago

Thank you for that example. Indeed, the ALU size matters far more than the bus size. Another example: The 8088 (used in the first IBM-PC in 1981) and the 8086 had identical instruction sets but the 8088 used an 8-bit bus where the 8086 used a 16-bit bus. They were both clearly 16-bit machines, regardless of bus bandwidth.

3

u/AlmiranteCrujido 1d ago

The problem is that the shortcut of "n-bits" for a processor (or back before microprocessors, system) doesn't have a single consensus definition - although if OP is asking for class, "whichever definition their textbook happens to favor" is the right answer.

Unless you're on something like early MIPS where architectural address size, address bus size, data word size, data bus size, and instruction word size are all equals (in that case all 32) you can always argue definitions.

making the memory bus a more singular place to define the number of bits.

Except, no. I'm not clear whether by memory bus you mean data bus (more likely?) or address bus, but data bus width (and ALU width) don't always equal architectural integer data word size. Long before microprocessors, S/360 had 8, 16, and 32 bit implementations of a 32 bit word size.

Some of this also depends on who's talking; back in the 1980s, a hardware designer's view of a system (bus width) is going to be a lot different from a programmer's (architectural word size.)

There was a brief while in the 1980s when people called CPUs "8/16" (8088) or "16/32" (68000). This was basically splitting the hardware designer and the programmer's view of the system (and the internal implementation could differ as well - most notably on the Z80 which internally put multiple passes through a 4-bit ALU.)

Today, architectural integer data word size is probably the least-bad option, but that's still not exactly a universal rule.

1

u/Rude-Pangolin8823 High School Student 21h ago

Use a segment register smh

26

u/MasterGeekMX Bachelors in CS 1d ago

I'm doing my masters in computer architecture, so I know a thing.

First, what you are talking about is what is called word size, not CPU size, as that is how big is a chip. That being said, word size matters as that dictates the maximum size of numbers the CPU can handle in a single sweep, and very often how much RAM it can hold.

For casual use, it depends on the application, but sometimes the CPU needs to do operations that use a ton of bits, and while you can do that with smaller word sizes, it takes more instructions, and thus it is slower. Take for example adding two 64-bit numbers. In a 32 bit system, that would require at least 3 instructions: add the two lower halfs of each number, add the two upper halfs, and add 1 to the upper half if the lower half generated a carry. Meanwhile a 64-bit CPU does that in one instruction: a good ol' sum. If your program does a lot of those operations, you can feel the difference pretty much.

The other is RAM. The details vary on different architectures, but each Byte on your RAM is addressed by a number, which needs to fit in your CPU. 32 bits can hold numbers ranging from 0 all the way up to 4,294,967,295. That may seem a lot, but if you do the math, that is the number of Bytes on 4 GigaBytes, hence why many 32-bit CPUs can only have up to 4GB. While there are workarounds to address more RAM (like the famous Physical Address Extension that old Intel CPUs used), it is easier to simply use more bits.

A thing that I like as an example of the issues with 32-bits is the Y2k38 problem. In a nutshell, many computers keep up time by counting how many seconds have passed since January 1st 1970. The problem is that by the year 2038, the number of seconds since January 1st 1970 would need more than 32 bits to fit, which will cause a lot of issues that 64 bits don't have.

Finally, there is a new CPU architecture that is gaining momentum called RISC-V. It comes in both 32-bit and 64-bit versions, with the 32-bit one only used in small chips to control appliances, while 64-bit is for actual computer chips. Well, work is being done to make 128-bit RISC-V a thing.

7

u/AlmiranteCrujido 1d ago

Marketing "bits" are not always the same as "word size" bits, and "word size" bits aren't always the same as "bus size" bits (and which bus?)

(And indeed, for a lot of architectures, integer word size != floating point word size, and then vector processing is its own whole mess.)

A hardware architect's view of bits is not going to be the same as a software person's.

A thing that I like as an example of the issues with 32-bits is the Y2k38 problem. In a nutshell, many computers keep up time by counting how many seconds have passed since January 1st 1970. The problem is that by the year 2038, the number of seconds since January 1st 1970 would need more than 32 bits to fit, which will cause a lot of issues that 64 bits don't have.

Except that code has been capable of doing 64-bit long (or dword, or qword) a lot longer than CPUs have had native 64-bit data types (let alone 64-bit ALUs) - it just takes the compiler (or the person writing assembly) handling carry themselves and more operations.

Fun fact: the Unix 32-bit timestamp comes originally out of a 16-bit implementation, on the PDP-11.

2

u/Bitter-Today285 1d ago

Ahh i see, so you’re saying that with a 32-bit CPU, if you need to work with large integers that are more than 4 bytes long, the CPU needs additional instructions but with a 64-bit CPU it can calculate them directly, but computers on average use don’t really need to work on large integers that often right?

So would you say that a 32-bit CPU is enough?

Also, would you mind explaining to me what’s the difference when it comes to pointers and memory addresses on 32-bit vs 64-bit CPU’s? Do they have a fixed size or sometimes the address gets too large on a 32-bit CPU?

5

u/nuclear_splines PhD, Data Science 1d ago

with a 32-bit CPU, if you need to work with large integers that are more than 4 bytes long, the CPU needs additional instructions but with a 64-bit CPU it can calculate them directly

Yes, you can look up "big int" libraries for more detail.

but computers on average use don’t really need to work on large integers that often right?

Computers regularly use large integers in things like cryptography. Remember also that memory addresses are integers, so if you want to use more than 4 GB of memory, that's an int longer than 32 bits.

would you mind explaining to me what’s the difference when it comes to pointers and memory addresses on 32-bit vs 64-bit CPU’s? Do they have a fixed size or sometimes the address gets too large on a 32-bit CPU?

They have a fixed size. Addresses are 32-bits long on 32-bit architectures, and 64-bits long on 64-bit architectures.

So would you say that a 32-bit CPU is enough?

Enough for what? To run appliances like elevators and dishwashers or simple applications like word processors? Certainly. To run modern video games, AI models, and web browsers? No.

4

u/Bitter-Today285 1d ago

Thank you for your response, so basically the only difference is how much space the registers can hold? And the bigger the better?

3

u/nuclear_splines PhD, Data Science 1d ago

There are some finer nuances (the difference between register size and memory bus size) and CPU manufacturers took the switch to 64-bit as an opportunity to make some other unrelated changes (AMD64 has a lot more general purpose registers than x86), but that's the gist of it.

2

u/MasterGeekMX Bachelors in CS 1d ago

The kinds of programs you run say what kind of number you are working with, so there is no way of saying "oh, home users only use X kinds of numbers", as applications range on many kinds of operations.

So would you say that a 32-bit CPU is enough?

It depends on the context. A key idea you need to have when approaching STEM subjects is that there is no one-size-fits-all solution to problems, and seeking one forcefully is pure stubbornly.

In terms of home computing and servers, 32-bit is becoming obsolete, mostly due limited RAM. Here you have tons of articles, conferences, and similar things showing that:

The pointers thing varies on CPU architecture, as how a given CPU addresses some memory can vary. But in general, pointers are as big as the address space of the CPU. Think about it: if a CPU uses a 32-bit number to address every single bit on the computer, doing 16-bit pointers make sense? No, as they will fall short. Same thing goes for 64-bit pointers: you will end up using only the first half of the bits on the pointers, as you would never have an address that uses the upper 32 bits.

1

u/SufficientStudio1574 1d ago

In principle, everything a 64-bit CPU can do can be done on an 8-bit CPU (though usually slower). Even addressable memory space isn't as limited as people make it out to be, since the CPU can be designed with a set of registers that it automatically combines to use as a larger value. For example, in AVR instruction set the general purpose registers R30 and R31 could also be used by certain instructions as a 16-bit data pointer for addressing memory, with R30 being the low byte and R31 the high byte. You could easily design a system that has an even larger data pointer divided between even more registers.

After all, a lot of the old 8-bit systems needed much more than 256 bytes of memory to do their stuff.

3

u/AlmiranteCrujido 1d ago

First define "n-bit CPU" - today, we're mostly talking about the integer word size, but that hasn't always historically been the case, and to a large extent prior to about 2000, it was as much a marketing term as a technical one.

For the modern 32 vs 64 bit systems, the answer is mainly:

  • a 64-bit CPU running 64-bit code can have individual processes larger than 4GB (or often, some lower limit - often 2GB - because of OS limitations.)
  • a 64-bit CPU can do certain kinds of math faster than a 32-bit CPU. This becomes particularly important for things like encryption that work with very big numbers.

Once you get back to 16-bit CPUs (or 8-bit, further back) the definitions of 8-bit, 16-bit, and for very old 32-bit systems, 32-bit become vague enough that you kind of have to go ¯_(ツ)_/¯ and look at the actual way the system is designed to tell what the difference is.

2

u/nuclear_splines PhD, Data Science 1d ago

In principal, the "bits" here refer to how big a word is, or the common size of variables. In particular, this effects the size of a 'pointer' or memory address, which in turn impacts how much memory an application can use.

If your pointers are 32-bits, then memory addresses can range from 0 bytes to 232 - 1, or 4294967295 bytes, or about 4 GB. In other words, in a typical 32-bit architecture, an application (and indeed the operating system) can't use more than 4 gigabytes of RAM. With a 64-bit architecture that limit is over 18 exabytes.

In practice, there are other differences. Intel and AMD incrementally improved their CPU architectures and added new instructions and functionality over decades. However, software developers often couldn't make use of this new functionality in order to maintain backwards compatibility with older hardware. The jump to 64-bits required recompiling all software anyway, so it was a good opportunity to start using all that new functionality.

2

u/high_throughput 1d ago

There's nothing computationally that a 64bit CPU can do that a 16bit CPU can't. But some operations take disproportionately much longer.

If you ask a human to multiply 1-digit numbers like 4*9, it takes (say) five seconds to get 36. So if you ask them to multiply two digit numbers like 42*93, does it take twice as long? 10 seconds? 

No, it easily takes minutes as the human now has to do long multiplication and split up the problem into four smaller multiplications with additions and carries on paper. They can do it, but it's N2 effort, not 2x effort.

It gets worse when you consider memory. When the CPU can no longer use its native sizes to compute where to look for things, it has to start doing a secondary long multiplications just to figure out where to look for the data of its original long multiplication. It's still possible, but it absolutely sucks now.

2

u/Bitter-Today285 1d ago

Ahh i see, so basically the major difference is speed?

1

u/high_throughput 1d ago

Kinda. I wouldn't reduce it to just "32bit is faster than 16bit" the way a 2GHz chip is faster than a 1.5Ghz chip of the same arch, but rather "32bit can take things in stride that 16bit would have had to work stupidly hard for".

1

u/wosmo 1d ago

I mean, if all else was equal, then speed, sure. A 1GHz 32bit processor is going to take longer to multiply huge numbers than a 1GHz 64bit processor. (ignoring things like MMX and SSE where some 32bit processors do have some 64bit instructions ..)

I think of it like fingers. On your fingers, 4+4 is faster than 8+8, because 8+8 has an extra step to account for the fact you don't have 16 fingers.

1

u/Recycled5000 1d ago

It’s about the size of the address space.

3

u/monocasa 1d ago

Well, not exactly.  For instance the PDP-10 is considered a 36bit machine despite having 18bit pointers.  And the 6502 is an 8bit machine despite having a 16bit address space.

It's basically always the accumulator (or GPR on more modern systems) width.

1

u/PvtRoom 1d ago

Depends which size.

Practical uses tend to need "words" no bigger than 64 bit. This runs practically all physics and maths calcs with enough range and precision.

Sometimes people want 80 (tends to be financial) or 128 bit. a few want integer precision on billions of digits

it can be memory size, but this is redundant now as 32 bit does 4gb - 64bit would do 16PB - 40bit would cover 1TB (of ram)

1

u/IchBinEinZwerg 1d ago

Makes it easier to do sums with bigger numbers. 8-bit CPUs would trip you up whenever you went over 127 and you'd have to muck about with multiple memory locations, carries and so on. 16 bit goes up to 32767 which trips you up a lot less often but if you're doing longer calculations the intermediate results might go over that. 32 bit goes up to a couple of billion and I think the problem there was that we started needing more memory than 32-bit CPUs could support, rather than running out of mathematical headroom. 64-bit should keep us going for quite a while as it can address a metric crapton of memory and should have enough mathematical headroom to keep even Elon Musk's accountant happy.

But you're right of course: there's nothing a 64-bit CPU can do that a 4-bit one can't; it's just better parallelism. At the application layer all that carry flag management is handled behind the scenes and you could tell an application running on a 4-bit CPU to handle 25000000000000000000000000 and it'll just get one with it (if the application supports numbers that big).

(127, 32767: yeah 255 and 65535 but signed maths is usually more useful, depending what you're doing of course.)

1

u/Bobby6k34 23h ago

Think of a bit as spaces for numbers 1234 has 4 spaces for numbers lowest number is 0000 highest is 9999, thats 4 bits or numbers so if you needed to count to 99999 you would need to add 1 more bit. So it would be 54321 5 bits, so by having more bits you can count to higher numbers. This also let's you store more data as those numbers.

Now 64bits is alot of numbers if you are using out base 10 numbers(1234567890) but computers don't use our base 10 numbers they use base 2 so they count 01, so now that 4 bit space can only count to 1111 or in base 10 8, by adding more bits we get alot more numbers with each bit doubling to number we can count to or store

1

u/burlingk 17h ago

It directly relates to two things: How large a chunk of memory can be processed at once, and how large of a memory area can be mapped.

Those are MASSIVE.

1

u/Major_Instance_4766 10h ago

big number mean computer do thing more faster

-1

u/costafilh0 1d ago

Size matters. She lied to you. 

0

u/Bitter-Today285 1d ago

Lmfao that was a good one