3 ms·

I agree with you. The 6502 isn't anything at all like RISC, it's "we can only just barely make a computer at all with the number of transistors we have availabl

I agree with you. The 6502 isn't anything at all like RISC, it's "we can only just barely make a computer at all with the number of transistors we have available". The 6502 uses a similar number of transistors as the 6800 (different company, but largely the same designers) but is MUCH faster in actual practice. The 6800 is a lot simpler and more orthogonal, the 6502 is a lot trickier and more efficient. What the ARM designers liked about the 6502 was that it read or wrote a byte from memory on every clock cycle, and you could quite accurately calculate the execution time of a 6502 program just by counting the number of bytes of instructions and data read and written (and for each instruction applied min(bytes, 2)). They are on record as saying they tried to duplicate this in a 32 bit CPU. Making maximum use of memory cycles without a cache was also the reason for ARM's load/store multiple instruction, so that a single 32 bit opcode could then drive up to 16 words of data read/write before needing to fetch another instruction. This feature became redundant (as least as far as speed went) once instruction caches were introduced, but ARMv7 CPUs are mostly running without caches to this day. ARMv8-A removed load/store multiple.

kragen 4y ago
The 6502 is pretty amazing. I mentioned the LDM/STM thing in https://news.ycombinator.com/item?id=33060256 https://news.ycombinator.com/item?id=33060256. As you of course know very well, but some other commenters may not, RISC-V omitted LDM/STM as well, even in the compressed-instruction extension; Waterman's dissertation includes a chapter where he measures the cost of providing LDM/STM in "millicode" instead of the instruction set, finding it quite reasonable, but this of course assumes the millicode is getting served out of the cache (at least most of the time) instead of its instruction fetches competing with the data traffic for memory bandwidth.
- brucehoult 4y ago
  Right. A form of this millicode LDM/STM is implemented in gcc and clang when invoked with the -msave-restore flag. This calls one of a set of (intertwined) functions on function entry. The called function saves N registers s0 .. s[N-1] plus the Return Address register on the stack. The millicode can save the RA from the original function because RISC-V allows using any register for the return address and the save-restore millicode uses a different one: t0 (register 5) instead of ra (register 1). The corresponding restore function is jumped to (tail called) at the end of the function and restores s0 .. s[N-1] and then returns to the caller of the original function. The three extra jump instructions involved with using -msave-restore (one each call, return, and tail-call) of course add several clock cycles. But I have seen code using -msave-restore run faster than code not using it because of better utilisation of the icache. In particular, I have seen this with CoreMark on a machine with 16 KB icache where -msave-restore gave a 3% speed improvement. At one point, the millicode for -msave-restore was 96 bytes of code. I don't know whether anyone has tweaked it since, but that is a pretty minor part of most icaches.

kragen 4y ago

The 6502 is pretty amazing. I mentioned the LDM/STM thing in https://news.ycombinator.com/item?id=33060256 https://news.ycombinator.com/item?id=33060256. As you of course know very well, but some other commenters may not, RISC-V omitted LDM/STM as well, even in the compressed-instruction extension; Waterman's dissertation includes a chapter where he measures the cost of providing LDM/STM in "millicode" instead of the instruction set, finding it quite reasonable, but this of course assumes the millicode is getting served out of the cache (at least most of the time) instead of its instruction fetches competing with the data traffic for memory bandwidth.

brucehoult 4y ago
Right. A form of this millicode LDM/STM is implemented in gcc and clang when invoked with the -msave-restore flag. This calls one of a set of (intertwined) functions on function entry. The called function saves N registers s0 .. s[N-1] plus the Return Address register on the stack. The millicode can save the RA from the original function because RISC-V allows using any register for the return address and the save-restore millicode uses a different one: t0 (register 5) instead of ra (register 1). The corresponding restore function is jumped to (tail called) at the end of the function and restores s0 .. s[N-1] and then returns to the caller of the original function. The three extra jump instructions involved with using -msave-restore (one each call, return, and tail-call) of course add several clock cycles. But I have seen code using -msave-restore run faster than code not using it because of better utilisation of the icache. In particular, I have seen this with CoreMark on a machine with 16 KB icache where -msave-restore gave a 3% speed improvement. At one point, the millicode for -msave-restore was 96 bytes of code. I don't know whether anyone has tweaked it since, but that is a pretty minor part of most icaches.