8 vs 16 vs 32bit MCUs

Hi all,

Having completed a good number of successful projects with AVRs and the Arduino IDE with a large number of I/O etc - I find it strange that I'm asking a question, to which I still don't truly understand.

What really, is the difference between an 8-bit MCU, a 16-bit etc etc? All the resources seem to point to PC related arguments of 32 vs 64bit processors. Most pages simply state larger = faster etc, fine - but why? Another example, 32bit PC processors have a 3.25GB RAM limit without a technique called some line like POE, I do not remember. Again, why are these limits imposed?

For example, how does an MCU with 8 bits create values larger than 255 - as clearly that is a binary 11111111. I have also read for example than an array is limited to 16 x 16 with an 8-bit MCU for a possible 256 values?

Most pages simply state larger = faster etc, fine - but why?

Mainly because the registers that hold the data that the machine operates on is wider. Therefore you are operating on more data with one instruction and you don't have to load a byte do the operation and store it back in memory and repeat until you have processed as many bytes as you need. This is known as the width of the data bus.

Another example, 32bit PC processors have a 3.25GB RAM limit without a technique

The amount of memory you can directly access is defined by the width of the data bus. On an 8 bit machine this was 16 bits allowing you to only access 64K of memory. The instructions that say load or store this memory only take a 16 bit address as an argument. So 32 bit processors have a much wider address bus as well as a data bus.

how does an MCU with 8 bits create values larger than 255

By splitting it up over a number of bytes.

Thanks for the response - there's a little piece of logic in my head that is finding it hard to understand how on an 8-bit MCU, there are other features that are higher bit values. Not so much for example the ADC, as the result is simply split up over a number of bytes, as you have explained - but things like addresses for external RAM, how can this be 16bit with an 8bit MCU.

Clearly that logic isn't correct, as it works however.

So, i've always thought a byte is 8 bits - but, on a 16bit MCU - would that make a byte 16 bits?

Also, any input regarding array sizes and maximums?

32bit PC processors have a 3.25GB RAM limit without a technique called some line like POE,

A 32-bit processor normally (always?) also has a 32-bit address bus. 2^32 is about 4.29gig so that's the limit of addressing unless you want to get into bank switching or MMUs. On a PC I think the 3.25 limit is for other reasons, maybe a gig is used by the OS or something.

As for POE, AFAIK that's Power Over Ethernet.

In the term "N-bit processor" the N refers to the data bus, the address bus it a different thing. There is no reason that an 8-bit processor can't have a 32-bit address bus, conversely a 32-bit processor could have a smaller address bus. You will notice that many chips like the Mega1284 and 2560 actually address 128 or 256k of flash, that means their address bus is 17 or 18 bits. Yet they are called an 8-bit processor because the data bus is 8 bits.

Some 16-bit processors like the 68000 had 24-bit address busses. So there is no real connection between the size if the address and data busses.

So, i've always thought a byte is 8 bits - but, on a 16bit MCU - would that make a byte 16 bits?

A byte is 8 bits end of story (OK it was 9 bits on some mainframes but let's not worry about that) regardless of the processor. The difference is that a 16-bit CPU can work on two of them at once, and a 32-bitter can work on 4. In fact having a 32-bit processor work with single bytes can slow your program down.

On the ARM IIRC a 16-bit entity is called a half-word and 32 bits a word, but when programming it's best not to use such terms because they mean different things to different processors and people. EG a "word" on an AVR would probably be considered to be 16 bits, on an ARM it's 32 bits.

And just to confuse things the term "int" normally refers to the native data element of a processor (ie the width of the data bus) which on a 32-bitter is 32 bits, however all 8-bit processors have int sizes of 16 bits, go figure. I guess the powers that be decided an 8-bit int was not much use.

Another reason 32-bitters are faster is really just technology, they tend to be newer designs and as such have better goodies like instruction pipelining, PLLs to multiply clocks etc.

Also, any input regarding array sizes and maximums?

Only limited by the addressing capability of the processor. I think Mike is correct, the C compiler will get around any native limitations of the processor. I've not tried it though.


Rob

Besides the others' comments, you can read about how 8-bitters do 16-bit maths, eg here,

http://www.8052.com/math

The saving grace is that they have a "carry bit" in the status/etc register that gets set
appropriately when there is an overflow when adding or subtracting two 8-bit numbers;
the carry/borrow is used just like you learned arithmetic in 3rd grade. Therefore,
arithmetic can be extended to any precision you want. The C compiler takes care
of all this automatically.

16- and 32-bitters do the same thing, except using wider numbers and therefore are
much faster. A big improvement will also occur when doing floating point.

any input regarding array sizes and maximums?

Array size is just a software thing not limited by the processor type, just by how much memeory you have. What is that last word?

The bit number quoted for a given MCU/CPU is a lot of the time just a marketing number. There is some basis in reality, but the actual choice is marketing.

A good example was the 8088 CPU. It had 16 bit registers. 8 bit data bus. 20 bit addressing bus. They called it a 16-bit micro but any of these might have applied.

80286: 16 bit registers. 16 bit data bus. 24 bit address bus. What a hack. Also called a 16-bit micro.

Pentium Pro/II/III/4: 32 bit registers. 32 bit data bus. 80 bit registers for the floating point stuff (and 128 bit registers with the introduction of SSE). But a 36-bit address bus. They should have called it a 36 bit CPU just to keep people irritated to this day. Too bad they didn't.

All of the classic 8 bit CPUs (6502, Z80, etc) had 16 bit address busses. A 256 byte memory would have been a letdown even in 1979.

Atmel's "8-bit" processors can have up to 256K of memory, that means an 18 bit address bus.

A more comprehensive answer might be read and understand the data sheet and don't let this marketing stuff get to you. Also, a computer architecture course wouldn't hurt.

A good example was the 8088 CPU. It had 16 bit registers. 8 bit data bus. 20 bit addressing bus. They called it a 16-bit micro but any of these might have applied.

Not really. A CPU is an 8-bit CPU if the width of the "arithmetic and logic unit" (ALU) is 8bits. The 8088 has 16bit registers and a 16bit ALU, so it was genuinely an 16bit CPU. It had an 8-bit EXTERNAL data bus to allow it to use cheaper memory systems (the internal databus was 16bits, just like its big brother the 8086.)
In the same timeframe, the motorola 68000 has 32bit registers and a 24 bit address bus, but it still had a 16bit ALU and is classified as a 16bit CPU.
In microcontrollers, it is also pretty common for the instruction memory to have a different width than the data memory. In an AVR, the instruction memory is 16bits wide, but the data memory and ALU are only 8bits wide. A Microchip 8-bit PIC comes in varieties with 12, 14, and 16-bit wide instruction memories, but the ALU is always 8bits. (there are 16 and 32bit cpus with the PIC label as well.) These also have separate memory spaces for data and instructions. So while there are AVRs with up to 256k of program memory space, they can only have 64k of data memory.

Array size can be limited by other factors. While a compiler can theoretically correct for a lot of things, many will insist that an array be contained within a single "page" of memory, accessible via some cpu-standard indexed addressing mode. The 8-bit PICs (or some of them, anyway) have data memory that is not contiguous, and things get difficult if an array contains more than 96 bytes. (OTOH, these chips typically have less than 400 bytes of data memory, anyway...)