3 ms·

Actually, despite being classed as a 16bit processor, the 68000 has 32bit registers and can move upto 4x as much data per instruction. It gets really hard to a

by phire 5y ago

Actually, despite being classed as a 16bit processor, the 68000 has 32bit registers and can move upto 4x as much data per instruction. It gets really hard to actually compare processing speeds across architectures. Your 32bit registers might really help accelerate 32bit math, but aren't going to do a thing for 8bit stuff like text processing. Also the 32bit versions of instructions took longer than 16bit versions, as the 68000 only had a 16bit data bus, and a 16bit ALU.

vidarh 5y ago
It can move much more per instruction with MOVEM which let's you move many full registers at once.
KerrAvon 5y ago
Was it Fred Brooks or John Mashey who said we should classify CPUs by register size (so the 68000 is a 32-bit CPU on the grounds IIRC that, to software, the 16-bit ALU and data bus are implementation details)?
- phire 5y ago
  The whole "bitness" of CPUs is a weird concept. I dislike the "register size" definition, because it kind of falls apart on modern CPUs. Which register should you be measuring? If it's the GPRs, then we will probably be stuck with 64bit CPUs forever, which is boring. Perhaps we should allow the vector registers to be counted? That would mean most modern CPUs are 256bit, but some Intel CPUs are 512bit. What about fpu registers? That would make the 8088+8087 an 80bit cpu, despite it's tiny 8bit bus. Personally, I think we should be using a definition that roughly scales with the the performance of the CPU, rather than the software API. I quite like the idea of memory-bus width. That would fix the 68000 at 16bit, where it arguably belongs, but would make some weirdness with the 8086 and it's 8088 sibling being 16bit and 8bit. But then again, that does actually reflect re-world performance between the two. It gets a bit complicated once CPUs start gaining caches, but I propose we measure the bus width between the CPU core and it's L1 cache. Most modern high performance CPU designs can move actually transfer multiple registers (commonly three) to/from L1 cache every single cycle. Since those registers can be 256bit, that would make them a 768bit cpu. Though if we start talking about per-cycle data transfers, we really should go back and update older CPUs to how much data they can actually transfer per cycle? Since it takes the 68000 12 cycles to transfer 32bits of data to/from memory, that would really make it a 3bit cpu. The z80 would become 1bit, and the 6502 would be 2bit (remember, the 6502 does one memory transfer per cycle, while most other 8/16bit CPUs do one memory transfer every 4 cycles), and the 8080 would be 0.62 bits. You just can't win. Might be better to just to write-off the entire concept of bitness as flawed.

by phire 5y ago

vidarh 5y ago

It can move much more per instruction with MOVEM which let's you move many full registers at once.

KerrAvon 5y ago

Was it Fred Brooks or John Mashey who said we should classify CPUs by register size (so the 68000 is a 32-bit CPU on the grounds IIRC that, to software, the 16-bit ALU and data bus are implementation details)?

phire 5y ago
The whole "bitness" of CPUs is a weird concept. I dislike the "register size" definition, because it kind of falls apart on modern CPUs. Which register should you be measuring? If it's the GPRs, then we will probably be stuck with 64bit CPUs forever, which is boring. Perhaps we should allow the vector registers to be counted? That would mean most modern CPUs are 256bit, but some Intel CPUs are 512bit. What about fpu registers? That would make the 8088+8087 an 80bit cpu, despite it's tiny 8bit bus. Personally, I think we should be using a definition that roughly scales with the the performance of the CPU, rather than the software API. I quite like the idea of memory-bus width. That would fix the 68000 at 16bit, where it arguably belongs, but would make some weirdness with the 8086 and it's 8088 sibling being 16bit and 8bit. But then again, that does actually reflect re-world performance between the two. It gets a bit complicated once CPUs start gaining caches, but I propose we measure the bus width between the CPU core and it's L1 cache. Most modern high performance CPU designs can move actually transfer multiple registers (commonly three) to/from L1 cache every single cycle. Since those registers can be 256bit, that would make them a 768bit cpu. Though if we start talking about per-cycle data transfers, we really should go back and update older CPUs to how much data they can actually transfer per cycle? Since it takes the 68000 12 cycles to transfer 32bits of data to/from memory, that would really make it a 3bit cpu. The z80 would become 1bit, and the 6502 would be 2bit (remember, the 6502 does one memory transfer per cycle, while most other 8/16bit CPUs do one memory transfer every 4 cycles), and the 8080 would be 0.62 bits. You just can't win. Might be better to just to write-off the entire concept of bitness as flawed.