Hacker News Reader

Comment by bullen | Hacker News Reader

Isn't the comparison misguided as each 16-bit instruction can move twice as much data?

Or was that taken into account?

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.

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)?

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.

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

The 68000 takes 4 clock cycles (minimum) to access memory and can read or write 2 bytes. At 8 MHz that means that the 68000 has a memory bandwidth of (8Mclocks/s/4clocks)x2bytes = 4Mbytes/s.

The 6502 takes 1 clock cycle (which might be stretched if needed) to access memory and can read or write 1 byte; At 2 MHz the 6502 in the BBC has a memory bandwidth of 2Mbytes/s.

So going from the 6502 to the 68000 would only get you twice the performance. But the 68000 takes many more clock cycles to handle an interrupt compared to the 6502 and since the BBC Micro was designed around interrupts instead of DMA this would eat up all the performance gain. This was true of the 16 bit micros from National, Zilog and Intel as well.

The ARM2 takes 1 clock cycle (which can be stretched if needed) to access memory and can read or write 4 bytes. In addition, it can tell memory if the next access will be random or if it will be at the address following the current one. DRAM has to slow down the processor for random accesses (a RAS cycle followed by a CAS cycle) but can work at full speed for sequential accesses (just CAS cycles). That means that sometimes the ARM2 runs at 4 MHz and sometimes at 8 MHz - supposing an average of 6 MHz is very reasonable. So we are talking about a bandwidth of 6Mx4 = 24Mbytes/s. That is 12 times faster than the 6502 and 6 times faster than the 68000. And the ARM2 has a normal interrupt that is very fast plus a fast interrupt that is instantaneous.

Note that in theory you need "2MHz" DRAMs for the BBC's 6502 or an 8MHz 68000. But in practice if you want to share the memory between video and the CPU you will need 4MHz DRAMs. Which is what the ARM2 also uses, but without sharing with video. The solution is to fetch the video in chunks using the sequential CAS-only mode, put it in a FIFO and then feed the video that instead of directly. Which is what the MEMC/VIDC companion chips for the ARM2 did. Now the video still slows down the processor, but doesn't hog 50% of the bandwidth.

Yes, that's true.

Sophie Wilson's goal was to run BASIC at 6502 assembly speeds, and they couldn't do that with the processors they had available.

The first ARMs operated at ~4 MIPS, but of course they were 32 bits (registers and data bus), so they were a lot faster than the 68000 and the 6502.

Citing wikipedia: The ARM2 was roughly seven times the performance of a typical 7 MHz 68000-based.

OTH everything else also got wider: opcodes are 16 bits instead of 8 bit and immediates are 16 or 32 bits. If the 'benchmark' can work mostly with 8-bit numbers and within the 6502's zero page, 8- vs 16-bit data bus width shouldn't make much of a difference.

Reply on news.ycombinator.com