The 68000 is 16 bit internally, and can access memory only 16 bits at a time, but the instruction set was designed with future iterations in mind, and most instructions can operate on 32 bit quantities - with a performance penalty. (Because in essence it has to do the work in 2 stages.)
Whether this is enough to make it count as actually 32 bits is one for the philosophers.
Externally it had 16 bits for databus and 24 bits for addresses. That is why we later got the 32 bit clean ROMs as Apple used the upper unused 8 address bits for flags.
It has 32-bit registers, but it has a 16-bit ALU, so it's a matter of opinion if that makes it a 16 or 32-bit processor. I'd go with 32-bit in that it's instruction set gives the impression to the programmer that they are working with a 32-bit system.
And for more evidence, the Z80 is referred to as an 8-bit processor but has a 4-bit ALU.
The cycle counts really don't back this theory up. And indeed, from that link:
> Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.
Most 32 bit operations are slower than 16 bit operations because the external data bus is only 16 bits and most operations use the external data bus. But simple internal ops are faster at 32 bits, so that seems to indicate the 68000 is 32 bit internally.
There's a subtlety -- word adds are only 8 cycles when adding to an address register. They're 4 cycles to a data register. This is because the 68000 always does address computations in 32-bit, and 16-bit operands are sign extended to 32-bit when adding to an address register. A word add to a data register, on the other hand, only produces a 16-bit result. This is reflected by the canonical instruction being ADDA.W instead of ADD.W for address register destinations.
Interesting, thanks. I'd missed that particular detail, possibly because I used to do this stupid shit on the Atari ST and its instructions were quantized to the nearest nop (and so 6 cycles wasn't really a thing). Address register operations are always longs, and clearly the sign extension imposes some overhead. Given that pretty much every other long operation is slower, I imagine this is a case of getting lucky with the timing of the 16-bit internal operations.
ADDQ and ADDX are better instructions to look at, as are any with a Dn,Dn addressing mode. The long and word cases are the same number of instruction bytes, but the long case is still slower.
(Register-to-register moves are the same regardless of width, so presumably it has a 32 bit path for this. That's nice. But not as nice as it would be if it had a 32 bit path for everything. Which it really looks like it doesn't. This CPU has registers, but that can't save it.)
The 386SX was a similar story, and is normally thought of as basically 32bit. I think the perception difference may be down to timing; the 386SX came out _after_ the DX (with 32 bit data bus), so was thought of as a cheap 32bit chip, vs the 68000 which started off life with a 16bit data bus.
(Fun fact: there was also the 68008, which was a 68k with an 8 bit bus!)
From memory, the primary advantage of the 386SX was the ability to use a cheaper 16-bit motherboard layout and components. The lack of a 32bit bus mattered less when most software was written with 286 compatibility in mind, and the ISA bus was only 16-bits wide, which limited the utility of the 32-bit bus for fast graphics transfers.
The reduced 24-bit address bus was never a significant bottleneck during its commercial lifetime, as little consumer software at the time would require more than 4mb of RAM, and by the time it did the 486SX (32bit busses with no maths coprocessor) was the new value champion.
It started out as 16bit enhancement to previous product, and evolved into being a 32bit architecture over development time.
The separation of Data and Address registers are also result of how it evolved over time, AFAIK, ultimately because it allowed to make the CPU cheaper/easier to make. Another element is that 68000 at least has two layers of microcode - first microcode engine generates instructions interpreted by second microcode engine which finally actually drives execution units.
The data and address registers of the 68000 were 32 bits wide.
That reminds me of this old system settings panel https://lowendmac.com/2015/32-bit-addressing-on-older-macs/
I remember the "enable 32-bit addressing" part (but it's not pictured..)
The 68000 is 16 bit internally, and can access memory only 16 bits at a time, but the instruction set was designed with future iterations in mind, and most instructions can operate on 32 bit quantities - with a performance penalty. (Because in essence it has to do the work in 2 stages.)
Whether this is enough to make it count as actually 32 bits is one for the philosophers.
No, this is very wrong. The 68000 is 32 bit internally and it has 32 bit registers: https://en.wikipedia.org/wiki/Motorola_68000
Externally it had 16 bits for databus and 24 bits for addresses. That is why we later got the 32 bit clean ROMs as Apple used the upper unused 8 address bits for flags.
It has 32-bit registers, but it has a 16-bit ALU, so it's a matter of opinion if that makes it a 16 or 32-bit processor. I'd go with 32-bit in that it's instruction set gives the impression to the programmer that they are working with a 32-bit system.
And for more evidence, the Z80 is referred to as an 8-bit processor but has a 4-bit ALU.
1 reply →
The cycle counts really don't back this theory up. And indeed, from that link:
> Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.
2 replies →
According to https://wiki.neogeodev.org/index.php?title=68k_instructions_... the 32 bit register add on the 68000 is faster (6 cycles) than the 16 & 8 bit register add (8 cycles).
Most 32 bit operations are slower than 16 bit operations because the external data bus is only 16 bits and most operations use the external data bus. But simple internal ops are faster at 32 bits, so that seems to indicate the 68000 is 32 bit internally.
There's a subtlety -- word adds are only 8 cycles when adding to an address register. They're 4 cycles to a data register. This is because the 68000 always does address computations in 32-bit, and 16-bit operands are sign extended to 32-bit when adding to an address register. A word add to a data register, on the other hand, only produces a 16-bit result. This is reflected by the canonical instruction being ADDA.W instead of ADD.W for address register destinations.
Interesting, thanks. I'd missed that particular detail, possibly because I used to do this stupid shit on the Atari ST and its instructions were quantized to the nearest nop (and so 6 cycles wasn't really a thing). Address register operations are always longs, and clearly the sign extension imposes some overhead. Given that pretty much every other long operation is slower, I imagine this is a case of getting lucky with the timing of the 16-bit internal operations.
ADDQ and ADDX are better instructions to look at, as are any with a Dn,Dn addressing mode. The long and word cases are the same number of instruction bytes, but the long case is still slower.
(Register-to-register moves are the same regardless of width, so presumably it has a 32 bit path for this. That's nice. But not as nice as it would be if it had a 32 bit path for everything. Which it really looks like it doesn't. This CPU has registers, but that can't save it.)
The 386SX was a similar story, and is normally thought of as basically 32bit. I think the perception difference may be down to timing; the 386SX came out _after_ the DX (with 32 bit data bus), so was thought of as a cheap 32bit chip, vs the 68000 which started off life with a 16bit data bus.
(Fun fact: there was also the 68008, which was a 68k with an 8 bit bus!)
From memory, the primary advantage of the 386SX was the ability to use a cheaper 16-bit motherboard layout and components. The lack of a 32bit bus mattered less when most software was written with 286 compatibility in mind, and the ISA bus was only 16-bits wide, which limited the utility of the 32-bit bus for fast graphics transfers.
The reduced 24-bit address bus was never a significant bottleneck during its commercial lifetime, as little consumer software at the time would require more than 4mb of RAM, and by the time it did the 486SX (32bit busses with no maths coprocessor) was the new value champion.
1 reply →
The 68008 saw a lot of use in embedded and could easily create a whole microcomputer on a breadboard.
1 reply →
It started out as 16bit enhancement to previous product, and evolved into being a 32bit architecture over development time.
The separation of Data and Address registers are also result of how it evolved over time, AFAIK, ultimately because it allowed to make the CPU cheaper/easier to make. Another element is that 68000 at least has two layers of microcode - first microcode engine generates instructions interpreted by second microcode engine which finally actually drives execution units.