3 ms·

>Which pre-RISC simple CPUs are you thinking about? Would 6502 qualify? I know that the ARM team moved away from it to design its own actual RISC architecture,

by TMWNN 4y ago

>Which pre-RISC simple CPUs are you thinking about? Would 6502 qualify? I know that the ARM team moved away from it to design its own actual RISC architecture, but I've often heard it as being very RISC-like.

kragen 4y ago
I think the 6502 is a lot more like the PDP-8, except that it has variable-length instructions (interspersed opcode bytes and operands). Looking at my list above of RISC features: - fixed-length instructions: no - no microcode: the 6502's PLA amounts to fairly extensive microcode - usually one instruction per clock: the 6502 doesn't come close to this, in part because of its microcoded execution approach. http://www.6502.org/tutorials/6502opcodes.html http://www.6502.org/tutorials/6502opcodes.html shows that different instructions take from 2 to 7 cycles, depending on the addressing mode. - a load/store architecture (no memory operands to ALU instructions): because the 6502 has only one accumulator all its ALU instructions have memory operands, and generally several different addressing modes are available. - pipelined execution: no. - a large orthogonal general-purpose register set: no, although you can use the zero page as a register file (as on the PDP-8) you can't use data on it for addressing (unlike the PDP-8!) or ALU operations with anything except the A register. So I think the 6502 is in every way at an opposite extreme from RISC. Which is not to say it's overcomplicated — it's an amazingly simple processor, actually, almost an order of magnitude smaller than the ARM 1 or any other RISC processor, roughly on par with the much more limited PDP/8 — but that the design tradeoffs it embodies are very different from RISC. They're not particularly similar to the systems the IBM 801 was designed in reaction to, either, except I guess that the 6502, like the IBM 360 and 370, is byte-addressed and supports both decimal and binary arithmetic; and the low-end S/360 Models 30 and 40 used an 8-bit ALU, like the 6502, but they hid it from the user: https://www.righto.com/2022/01/ibm360model50.html https://www.righto.com/2022/01/ibm360model50.html
- brucehoult 4y ago
  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.

by TMWNN 4y ago

kragen 4y ago

I think the 6502 is a lot more like the PDP-8, except that it has variable-length instructions (interspersed opcode bytes and operands). Looking at my list above of RISC features: - fixed-length instructions: no - no microcode: the 6502's PLA amounts to fairly extensive microcode - usually one instruction per clock: the 6502 doesn't come close to this, in part because of its microcoded execution approach. http://www.6502.org/tutorials/6502opcodes.html http://www.6502.org/tutorials/6502opcodes.html shows that different instructions take from 2 to 7 cycles, depending on the addressing mode. - a load/store architecture (no memory operands to ALU instructions): because the 6502 has only one accumulator all its ALU instructions have memory operands, and generally several different addressing modes are available. - pipelined execution: no. - a large orthogonal general-purpose register set: no, although you can use the zero page as a register file (as on the PDP-8) you can't use data on it for addressing (unlike the PDP-8!) or ALU operations with anything except the A register. So I think the 6502 is in every way at an opposite extreme from RISC. Which is not to say it's overcomplicated — it's an amazingly simple processor, actually, almost an order of magnitude smaller than the ARM 1 or any other RISC processor, roughly on par with the much more limited PDP/8 — but that the design tradeoffs it embodies are very different from RISC. They're not particularly similar to the systems the IBM 801 was designed in reaction to, either, except I guess that the 6502, like the IBM 360 and 370, is byte-addressed and supports both decimal and binary arithmetic; and the low-end S/360 Models 30 and 40 used an 8-bit ALU, like the 6502, but they hid it from the user: https://www.righto.com/2022/01/ibm360model50.html https://www.righto.com/2022/01/ibm360model50.html

brucehoult 4y ago
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.