So what is a 32-bit CPU?

[woofy]

After reading the "Bootleg MCS-251, 32-Bit 8051" topic, I have to ask this age old question again because my opinion has changed.

Only a few years ago I would have said "No way, this thing is an 8-bit CPU". It has an 8-bit data path to its register file and data RAM, and 8 bit ALU. Now I'm not so sure.
Was the Z80 a 4 or 8 bit CPU? Everyone said it was an 8 bit CPU, then it was discovered that it had a 4 bit ALU and ran the computation twice within its 4 clocks/instruction to look like an 8 bit CPU. Everyone still refers to it as an 8 bitter.
Was the 68008 an 8, 16 or 32 bit CPU?
Is the RISC V SERV processor a 1 or 32 bit CPU?

So my current definition is:
If it can do a 32 bit computation in a single instruction, regardless of the clock cycle count, then its a 32 bit CPU. But its all a bit messy, and I'm sure there are exceptions to my definition.
So how do you folks define a 32 bit CPU?

[ataradov]

It does not matter how wide the actual ALU is, what matters is how it appears in the ISA.  If it has 32-bit registers and instructions operate on those 32-bit registers, then it is a 32-bit MCU.

SeRV implements RISC-V and has 1-bit ALU. I doubt anyone would argue it is a 1-bit MCU. Especially now you would have to argue implementation vs ISA, but from the compiler/programmer point of view only ISA matters. The only side effect of the implementation is performance impact.

And if you are going to argue micro-architectural details, then you will go nuts with x64 processors and their internal pipelines.

[tggzzz]

Ah, this old chestnut again

Consider the (commercially important) Elliott 803 computer: 39bit words (+parity in the memory), 19-bit instructions (2 per word plus a modifier bit), 1-bit ALU (i.e. bit serial), 13-bit address bus (8192kwords).

So, is it a 1/13/19/39 bit machine?

[coppice]

The PDP8 existed in various forms, from a serial implementation, working one bit at a time, to 12 bit wide versions. To the programmer they all looked like the same 12 bit processor. Are you going to say they were all different numbers of bits?

[brucehoult]

To me one thing is beyond question: all machines that run the same programs in their primary execution mode have the same bit-ness.

Implementation trade-offs involving size, cost, speed do not affect the bit-ness.

8080 and z80 have the same bit-ness.  8088 and 8086 have the same bit-ness. 68008 and 68040 have the same bit-ness.


Where I get more controversial is I think the size of memory addresses and registers to hold them and address arithmetic (without any bank switching, segments, or page tables) is more important than the width of arithmetic on data. The 80386 and 68030 are not 80 bit just because they can do arithmetic on 80 bit quantities. They are 32 bit because that is the size of their memory addresses.

Memory size is the main thing determining the problems a computer can practically tackle.

6800, 8080, 6502, z80 are in a different class to SC/MP or 8051 (which are genuinely 8 bit). They are much more powerful computers than PDP-8 (12 bit).

I count them as somewhat poor 16 bit computers.

A 6502 with bank switching added (externally, with memory-mapped bank registers) was quite competitive with an 8088 with its internal segment registers.

[Circlotron]

So, is it a 1/13/19/39 bit machine?

A bit like trying to pin down the model year of Johnny Cash’s car that he brought home “one piece at a time”. 

[brucehoult]

So, is it a 1/13/19/39 bit machine?

A bit like trying to pin down the model year of Johnny Cash’s car that he brought home “one piece at a time”. 

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

Back when the Mac II (68020) was new, I often made use of the 80 bit FPU's ability to do 64 bit integer arithmetic, but that didn't make it an 80 bit (or 64 bit) computer.

[tggzzz]

So, is it a 1/13/19/39 bit machine?

A bit like trying to pin down the model year of Johnny Cash’s car that he brought home “one piece at a time”. 

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

It wasn't primarily a floating point machine. That would have been remarkable in an era where hardware limitations caused languages to have fixed point arithmetic types and operations. I can't quickly spot the instruction timing for floating point operations; if I see him on 30th June at TNMoC, I'll ask Peter Onion.

It could only do integer arithmetic in that size. In the late 50s, "bytes" (of whatever size) hadn't been dreamed up.

For the 803, even lower case characters were out of the question, due to the 5 channel teleprinter tape used for i/o.

Back when the Mac II (6020) was new, I often made use of the 80 bit FPU's ability to do 64 bit integer arithmetic, but that didn't make it an 80 bit (or 64 bit) computer.

True, but what does unambiguously make it an X bit computer?

[ataradov]

One thing about "bitness" is that it does not really matter in general.

And where it matters, the number should come with exact description of what that number means. It is totally fine to have 32-bit registers and 48-bit bus. There is no point in trying to come up with some universal definition, since there will always be some hardware that does not fit the definition in a meaningful way.

[coppice]

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

It wasn't primarily a floating point machine. That would have been remarkable in an era where hardware limitations caused languages to have fixed point arithmetic types and operations. I can't quickly spot the instruction timing for floating point operations; if I see him on 30th June at TNMoC, I'll ask Peter Onion.

It could only execute a few hundred floating point instructions per second, but even its integer performance was like molasses.

[brucehoult]

One thing about "bitness" is that it does not really matter in general.

I agree.

What I care about is the size of the types offered by the C compiler (especially including pointers), and how fast it runs my programs, at what price and energy use.

If someone makes a 6502 that runs at 1000 GHz (optical computing maybe) with 32 GB RAM offered via bank switching and a C compiler that presents 64 bit pointers and integers, then I'd be jumping on that thing.

[tggzzz]

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

It wasn't primarily a floating point machine. That would have been remarkable in an era where hardware limitations caused languages to have fixed point arithmetic types and operations. I can't quickly spot the instruction timing for floating point operations; if I see him on 30th June at TNMoC, I'll ask Peter Onion.

It could only execute a few hundred floating point instructions per second, but even its integer performance was like molasses.

It was a 2kIPS machine; they cycle time was 576µs.

Even so, they managed to play music on it. I may even have a cassette tape of that somewhere The "Fetch ALGOL" operation sounded like a broody hen

[brucehoult]

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

It wasn't primarily a floating point machine. That would have been remarkable in an era where hardware limitations caused languages to have fixed point arithmetic types and operations. I can't quickly spot the instruction timing for floating point operations; if I see him on 30th June at TNMoC, I'll ask Peter Onion.

It could only execute a few hundred floating point instructions per second, but even its integer performance was like molasses.

2000 integer operations per second.

Floating point was very important in early computers as they were used at first for military, scientific, and industrial uses. Commercial use came later.

The 803 was used for artillery calculations, controlling nuclear reactors, aerodynamic simulation by aircraft designers.

Not for long, presumably, as the CDC6600 came along just a couple of years later, vastly faster but also vastly more expensive. And of course the IBM 360, which let you move the same programs down to cheap slow highly microcoded machines or up to very expensive fast direct hardware execution of most instructions -- the first deliberate Instruction Set ARCHITECTURE rather than a one-off implementation of whatever instruction set suited the hardware design.

[coppice]

Note that the Elliot had 39 bit data words and accumulator primarily because it was designed for floating point, with a 30 bit 2s complement mantissa and 9 bit exponent, although it could also do integer arithmetic in that size.

It wasn't primarily a floating point machine. That would have been remarkable in an era where hardware limitations caused languages to have fixed point arithmetic types and operations. I can't quickly spot the instruction timing for floating point operations; if I see him on 30th June at TNMoC, I'll ask Peter Onion.

It could only execute a few hundred floating point instructions per second, but even its integer performance was like molasses.

It was a 2kIPS machine; they cycle time was 576µs.

Even so, they managed to play music on it. I may even have a cassette tape of that somewhere The "Fetch ALGOL" operation sounded like a broody hen

I believe the entire ALU was bit serial, so its not surprising that things like multiply and divide were super slow. It was the very slow add and subtract that was painful. Those computers hung around for years in the Elliott, Marconi and GEC companies. A lot of engineers crossed their paths.

[PCB.Wiz]

After reading the "Bootleg MCS-251, 32-Bit 8051" topic, I have to ask this age old question again because my opinion has changed.
....
So my current definition is:
If it can do a 32 bit computation in a single instruction, regardless of the clock cycle count, then its a 32 bit CPU. But its all a bit messy, and I'm sure there are exceptions to my definition.
So how do you folks define a 32 bit CPU?

Besides computation size, the other area where 8-bit elasticity is showing is on op-code fetch.

Classic 8031 used external memory, and fetched one byte at a time, some opcodes needing 3 fetches before they could complete, in 6-12 clocks per byte.

Newer 1T 8051 can read one byte per clock, but some forgo external code memory, and can read  internal memory 24 or 32 bits wide.

Now, on the fastest STC parts, a 3 byte opcode can execute in 1 clock.  Surely that makes it a 24 bit CPU ?

STC also have moving goal posts on their 32 bit support.
They have MDU32C, (in latest silicon) and MDU32D (in planned silicon)

They also have FPMU in their STC32F12K54, for 32b floats.

I've not seen much published on STC for debug support, on single step / break points etc
They seem to focus on boot loaders and have a USB boot loader essentially for free on their STC8H..U parts.

[woofy]

One thing about "bitness" is that it does not really matter in general.

100%

I pretty much ignore bit size (and ISA) when selecting a microcontroller. It's much more about spec's and price. If it has the peripherals I need, enough grunt to get the job done, and price and availability ok, then that's what I select. More often than not the rich peripherals in a PIC16/18 means that is what I select on small jobs.

[woofy]

Where I get more controversial is I think the size of memory addresses and registers to hold them and address arithmetic (without any bank switching, segments, or page tables) is more important than the width of arithmetic on data. The 80386 and 68030 are not 80 bit just because they can do arithmetic on 80 bit quantities. They are 32 bit because that is the size of their memory addresses.

Hmmn!
Perhaps when I asked if the 68008 is an 8, 16 or 32 bit CPU, I should have said 8, 16, 20, 22 or 32 bit.
However I define the bit size of a CPU, and address width is certainly important in defining its capability, I don't think I'd include it in any "bitness" number.

[Berni]

I take "bitness" of a CPU as the largest number the CPU can easily operate on(without any extra speed penalty) using most of the registers and calculation instructions (sum,bitwise,shift..etc)

Once you get to 16bit and above it doesn't really matter anymore for MCUs. They can address 64K of memory and work with numbers large enough to represent most things. If you need more memory go 32bit. These days low bit count CPUs don't make much sense because the number of transistors on a chip has went up a lot, so it doesn't cost that much extra to create a 32bit CPU versus a 8bit one, also we no longer use pin hungry parallel memory busses to connect everything to the CPU.

It is the 8bit ones that are annoying to run modern languages on as they can't properly address any reasonably useful amount of memory. They were meant to run hand coded assembly, yes you can run C on them, but the C code you run on them has to be written with the CPU limitations in mind. Pointers don't work properly anymore, math with large numbers is slow and loves to truncate bits, strings are a pain with memory etc..

[Doctorandus_P]

It is the 8bit ones that are annoying to run modern languages on as they can't properly address any reasonably useful amount of memory. They were meant to run hand coded assembly, yes you can run C on them, but the C code you run on them has to be written with the CPU limitations in mind. Pointers don't work properly anymore, math with large numbers is slow and loves to truncate bits, strings are a pain with memory etc..

Meh, that's been solved by a few people writing compilers and compiler optimizations, while mere mortals, just use the compiler. You have to be aware of a few things, for example 32bit math is not atomic on an 8-bit processor, so you have to be careful with sharing data with ISR's and some other things, but mostly it does not matter much what processor you are using You just write C code (most often) and that's it. Going from assembly to C is a giant step forwards. Suddenly 95% of your code is processor agnostic and (sort of) portable.

I started programming in BASIC a very long time ago. Within a few weeks my dislike for the language was growing fast and I mostly stopped. Later I bought Turbo C++ (which had annoying bugs, so I "found" a copy of Borland C++) and I've written some nice programs with it.

When I started with microcontrollers, the pic16f84 was the only affordable option. Programming it in assembly was horrible. Later the Atmel at90S2313 was released and it had GCC. That was wonderful, and from there you re-use your code on processors with more Flash, RAM or MHz when needed. Now I'm dabbling into STM32, and porting most of the C code I've ever written is doable, (although not entirely painless).

[Berni]

When you are used to bigger 32bit MCUs and go back to 8bit MCUs running C, there is a sizable difference as there is suddenly a lot more things to watch out for. They become more apparent the larger of a application you try to write.

Not saying one shouldn't run C on 8bit MCUs, Assembler is awful to work in(especially on the 8bitters with awful ISAs like PICs). Just that the architecture of a lot of 8bit MCUs is not very well suited for running C. So with how cheap 32bit MCUs are getting there is not that much reason to keep using the old 8bit families unless the task it is doing is very simple and you want to squeeze cents out of the BOM. You can get a 32bit ARM dual core 133Mhz for $0.80 in the form of a RP2040. So if you plan to run any decently sized C program you might as well just buy a modern MCU that is designed for running high level languages and does it with a lot of performance.

I still use a 8bit MCU here or there, program it in C too, but just for simple stuff.

[yar]

This post ties into https://www.eevblog.com/forum/microcontrollers/rip-z80

I pretty much agree with the crowd here.  As programmers, we know I need to know about bus width, but it's generally true that *most* of the time, we don't have to deeply care. Sure, alignment constraints on memcpy-style interfaces are examples of things we sometimes have to know about, but we're probably not deeply designing around them.

Pentium Pro adding PAE did not mean that even those of us building the VM systems in OSes at that time ever started thinking of them as 36-bit computers.

My shortest answer (with excuses) would start with "about the size of void*, in bits". That's the size of registers for additions or masks or whatever for ints and longs in MOST sane architectures. (long long is intentionally not invited to this formula.)



To amplify a problem that Berni touched on, another reason for C developers to hate 8-bitters is that the compilers such both because the architecture often sucks (sdcc or cc65 is impressive that it can run C at all, but when you have only three registers, it's not like calling functions with values in registers would be practical even if you can get over no register being able to hold anything larger than a char...) and because the compilers themselves are just mutants. They're usually buggy, are feature-impoverished, never really standard compliant, have poorly implemented asm() facilities if they have it at all, are paired with terrible libc-like features and more.

Contrast that to the CH32V003 family of parts that have been well discussed here.  There's still not a great match for the dual-core RP2040 or ESP32 (far beyond the 8-bitters in question) but single-core devices from WCH and even Espressif (especially if you need radios anyway...) have lots of options that price well against comparable parts and are down solidly into the land of 8-bit micros.  CH32V003 has fifteen 32-bit (mostly) general-purpose registers and a sensible, well-documented ABI. As a programmer, you don't have to care about near vs far data or zero page or whether the arg list exceeds available calling registers. Software floating point libraries are part of the toolchain and have been heavily exercised.

For those cases where pennies DO count, it's really sweet to be able to use a current, stable, supported, often pre-installed version of the entire current GNU development stack (including libg++ if you're suitably disciplined) or (probably) LLVM toolchains. You can ignore WCH's hacked up versions of compilers and extensions to RISC-V itself like the fast interrupt stuff if you don't need them.  If you do, those things are documented well enough that they're usable and you can make an informed choice on whether moving to a vendor branch or staying on mainline tools is right for your project.

There's a LOT of value in sitting an engineering team down on day 0 and starting with 'apt-get riscv-g++' (whatever) and knowing that you're using normal C/C++ tools that are actively maintained, have been actually run through performance and regression tests, and have been used by others to build complete operating systems, browsers, and such. Sure, the RV32E path isn't quite as well traveled as RV64, but the front-ends, middle layers like optimization passes, and most of actual opcode handling is shared with the big boys. Your team doesn't have to relearn "ISO C[++]"; they can rely on the skills they've built over decades.

I totally respect the retro projects and understand why they have to live in their respective worlds. Go nuts! I just can't imagine starting an 8051, PIC, STM8 or AVR project in modern times.  Being able to rely on sensible pointers, data structures, debuggers, and generally very well-supported tools just makes suffering new projects on those needless for most cases. I know that the "but, aksually" guy will be along soon enough to explain why his company's alarm clock HAS to ship on some tortured tools forever and that's fine. There may be no value in replacing work you've already paid for, but just don't torture yourself (or worse, your team) with goofy tools when you don't have to any more.

I hope to never again program on hacked up Intel, Atmel, or other vendor-specific 8-bit (or honestly, other) toolchain.  The economics of RISC-V at the low end should hopefully starve out that development in a mere 25-40 years. :-|


P.S. I know that Paduk exists. That's just another SDCC target and while it might solve the formula for the value of "cheap", leaves open the issue of "well supported by mainline, quality tools".

[brucehoult]

My shortest answer (with excuses) would start with "about the size of void*, in bits"

Exactly. By far the most important spec in the system. Everything else is just speed.

With no "far pointer" rubbish.

CH32V003 has fifteen 32-bit (mostly) general-purpose registers and a sensible, well-documented ABI.

If you ignore the ABI (therefore program in asm) then they are 100% general purpose. RV32E does not distinguish them in any way.

The C extension is optimised around an assumption that you're following the standard ABI -- that x1 is RA, x2 is SP, x8-x15 are the most commonly used registers -- but if you don't follow the ABI the worst thing that happens is you don't get C extension instructions as often and your code will be bigger.

Of course it's much easier to just use a standard C compiler and therefor the standard ABI.

P.S. I know that Paduk exists. That's just another SDCC target and while it might solve the formula for the value of "cheap", leaves open the issue of "well supported by mainline, quality tools".

Ah yes, the 3c Padauk PMS150C ... 64 *bytes* of RAM and 1024 13 bit instructions. And something as simple as if (x<y){ some stuff } requires ...

Code: [Select]

    MOV A,x
    SUB A,y
    T0SN 3.2,0 // skip if carry clear (PIC BTFSC)
    GOTO $1
    // some stuff
$1:

... i.e. four instructions, 52 bits of code, where RISC-V is a single 32 bit instruction if some stuff is less than 4k of code.

The one good thing .. Padauk has a signed overflow flag, which PIC doesn't.

And the worst thing: the 3c Padauk is One-Time-Programmable, while the 10c CH32V003 has flash. Padauk have an otherwise identical (I think) chip with flash for 15c.

Non-bias statement: don't forget the Puya PY32F002 which is also 10c, flash based, and has more RAM (3k vs 2k) and flash (20k vs 16k) than the CH32V003. And it's 32 bit Arm, though the inferior Cortex M0+ (ARMv6-M) instruction set (same as Pi Pico) which is not as convenient as ARMv7 or RV32EC. But still, very well supported by standard gcc and clang.

[bson]

Another extreme example is the Saturn CPU used in the HP-48 series (and some other) calculators.  It has 64-bit registers, but 4-bit data bus, data paths, ALU and nibble-addressable (20 bit address) memory.  For word "sizes" it operates on register nibble (BCD digit) fields.  Ran at a few MHz.  https://en.wikipedia.org/wiki/HP_Saturn.  In more recent incarnations it was emulated by an ARM processor, until HP dropped the Corvallis division altogether.  It's an interesting example of a CPU optimized for one very specific purpose...

[tggzzz]

And then there's the Elliott 803, an influential machine. Tony Hoare (Quicksort, NULL, semaphores, CSP, Turing Award)) developed an influential Algol-60 compiler for it. The Elliott 803 was the computer used in the ISI-609, the world's first process or industrial control system, wherein the 803 was a data logger. It was used for this purpose at the US's first dual-purpose nuclear reactor, the N-Reactor.

39 bit word, 39-bit registers, 18/39-bit instructions, 13-bit addresses, 1-bit data path. Categorise that!

[brucehoult]

And then there's the Elliott 803, an influential machine. Tony Hoare (Quicksort, NULL, semaphores, CSP, Turing Award)) developed an influential Algol-60 compiler for it. The Elliott 803 was the computer used in the ISI-609, the world's first process or industrial control system, wherein the 803 was a data logger. It was used for this purpose at the US's first dual-purpose nuclear reactor, the N-Reactor.

39 bit word, 39-bit registers, 18/39-bit instructions, 13-bit addresses, 1-bit data path. Categorise that!

13 bit, but it came very very close to being 39 bit :-)

Although the accumulator (the only register except another to put the top half of a double-precision result) was 39 bits, that doesn't make it a 39 bit machine, just as the 80386 or 68020 having some 80 bit registers didn't make them 80 bit computers. And neither do the x86 string instructions.

How was it almost a 39 bit machine?

If the "B" bit between the two 19 bit instructions in a word was set then the new value of the 39 bit memory location pointed to by the first instruction (which is most often the same as the old value) is added to the 19 bit instruction in the second half of the word, before that instruction is decoded.  It's a simple arithmetic add, so that data word being added can alter not only the 13 bit address in the 2nd instruction (the most common use, for array indexing or simple pointer-chasing), it can also modify the opcode field. Or even overflow the address into the opcode. Ugh.

Since it has this indexed/indirect addressing ability there is no real need for a self-modifying code ability before instruction decode -- you can anyway just do that in memory. So they COULD HAVE instead used the entire 39 bit data word from memory as a base address added to the 13 bit offset in the 2nd instruction and had 39 bit addressing.

Not that anyone needed 2,748,779,069,440 bytes (2.7 TB) of memory (2,680,059,592,704 after subtracting the parity bit in each word) in the 1960s. They could probably barely afford the 40k bytes the machine actually supported.