5 ms·

I'm surprised that there aren't any specialised instructions or hardware resources to handle the RISC-V instruction decoding/dispatching. [1] Like, sure, it's

I'm surprised that there aren't any specialised instructions or hardware resources to handle the RISC-V instruction decoding/dispatching. [1] Like, sure, it's not meant to be a fast implementation, but even just a "mask byte with 0x7C and set PC to that value times 8" instruction (which in an FPGA implementation is just rearranging the wires) could save 5-6 cycles per instruction. Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? [1] https://github.com/brouhaha/glacial/blob/master/ucode/ucode.asm#L456 https://github.com/brouhaha/glacial/blob/master/ucode/ucode....

nullc 6y ago
I assume this would be an obvious starting point for looking at for the smallest specializations that give the greatest performance improvement. I understand that there are some FPGAs now that essentially have RISC-V ALU hard blocks, so use of them might be a speed and area improvements.
- brucehoult 6y ago
  The MicroChip "PolarFire SoC" FPGA chips have five 64 bit RISC-V cores (SiFive U54-MC) currently running at 600 to 667 MHz (depending on speed grade) inside. So far the only available device has 250k logic elements (LUT4 + FF) for $340 qty 1, but there are part numbers in the data sheet for other sizes in future. I have an "Icicle" board based on this chip. The FPGA comes preconfigured to boot Linux from the included pre=programmed SD card, so you can just use it to run Linux if you don't care about FPGAs. Or you can replace or enhance the default FPGA programming.
throwaway81523 6y ago
> Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? Don't know, but the amount of "microcode" or emulation code required is itself a reasonable measure of an ISA's complexity. Doing an x86 that way would surely take tons more code.
brucehoult 6y ago
Yes, an interpreter is exactly what microcoding is. See Maurice Wilkes' original paper, or the initial IBM 360 models (the lower end of which had an 8 bit CPU running the microcode), or the various VAX models etc. In those days the microcode ROM and ALU etc was substantially faster than RAM (core). At some point SRAM became as fast as or faster than ROM and machines copied the microcode into SRAM on startup. Some machines such as the Burroughs 1700 series loaded different microcode into SRAM depending on whether you wanted to run FORTRAN or COBOL programs. Then companies started allowing users to write their own custom instructions in microcode. See for example the VAX "Writeable Control Store" which on the 11/780 (as an option) gave users 1024 words (12 KB) for custom microcode and a microcode assembler and debugger. Some people even wrote compilers targeting this for languages such as Pascal (see for example https://apps.dtic.mil/dtic/tr/fulltext/u2/a089424.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/a089424.pdf) The next step was to turn the SRAM into a cache, and make a slightly more user-friendly microcode the actual instruction set used by all compilers, and thus RISC was born. Of course you are correct that specialised instructions to make instruction decoding easier are helpful in an ISA emulator. It would not surprise me to see RISC-V itself get an extension along those lines in the near future, to help M-mode software emulate unaligned loads and stores and other unimplemented instructions, but maybe also to help emulate other instruction sets.
- kiwidrew 6y ago
  > Yes, an interpreter is exactly what microcoding is. In a sense, yes, it is indeed! But when I think "microcode" then I think something like the 8086's horizontal microcode [1], where each line of microcode is wired directly to the various functional units and the microcode jumps and branches are (in some sense) determined based off (some of) the bits in the instruction register. Characteristics of microcode include: wide instructions (20-40 bits) that perform multiple operations in parallel (e.g. ALU operation and register-register copy) and hardware dispatch to the appropriate microcode to handle each microcoded instruction via zero-overhead multiway branches. I wouldn't call a 6502-like assembly language microcode, even if it implements an interpreter for a user-level instruction set, because it lacks the relevant characteristics of true CPU microcode. [1] https://www.reenigne.org/blog/8086-microcode-disassembled/ https://www.reenigne.org/blog/8086-microcode-disassembled/

nullc 6y ago

I assume this would be an obvious starting point for looking at for the smallest specializations that give the greatest performance improvement. I understand that there are some FPGAs now that essentially have RISC-V ALU hard blocks, so use of them might be a speed and area improvements.

brucehoult 6y ago
The MicroChip "PolarFire SoC" FPGA chips have five 64 bit RISC-V cores (SiFive U54-MC) currently running at 600 to 667 MHz (depending on speed grade) inside. So far the only available device has 250k logic elements (LUT4 + FF) for $340 qty 1, but there are part numbers in the data sheet for other sizes in future. I have an "Icicle" board based on this chip. The FPGA comes preconfigured to boot Linux from the included pre=programmed SD card, so you can just use it to run Linux if you don't care about FPGAs. Or you can replace or enhance the default FPGA programming.

throwaway81523 6y ago

> Is it really "microcoded" when all you're doing is writing a RISC-V emulator that runs on what looks to be a fairly standard 8 bit CPU? Don't know, but the amount of "microcode" or emulation code required is itself a reasonable measure of an ISA's complexity. Doing an x86 that way would surely take tons more code.

brucehoult 6y ago

Yes, an interpreter is exactly what microcoding is. See Maurice Wilkes' original paper, or the initial IBM 360 models (the lower end of which had an 8 bit CPU running the microcode), or the various VAX models etc. In those days the microcode ROM and ALU etc was substantially faster than RAM (core). At some point SRAM became as fast as or faster than ROM and machines copied the microcode into SRAM on startup. Some machines such as the Burroughs 1700 series loaded different microcode into SRAM depending on whether you wanted to run FORTRAN or COBOL programs. Then companies started allowing users to write their own custom instructions in microcode. See for example the VAX "Writeable Control Store" which on the 11/780 (as an option) gave users 1024 words (12 KB) for custom microcode and a microcode assembler and debugger. Some people even wrote compilers targeting this for languages such as Pascal (see for example https://apps.dtic.mil/dtic/tr/fulltext/u2/a089424.pdf https://apps.dtic.mil/dtic/tr/fulltext/u2/a089424.pdf) The next step was to turn the SRAM into a cache, and make a slightly more user-friendly microcode the actual instruction set used by all compilers, and thus RISC was born. Of course you are correct that specialised instructions to make instruction decoding easier are helpful in an ISA emulator. It would not surprise me to see RISC-V itself get an extension along those lines in the near future, to help M-mode software emulate unaligned loads and stores and other unimplemented instructions, but maybe also to help emulate other instruction sets.

kiwidrew 6y ago
> Yes, an interpreter is exactly what microcoding is. In a sense, yes, it is indeed! But when I think "microcode" then I think something like the 8086's horizontal microcode [1], where each line of microcode is wired directly to the various functional units and the microcode jumps and branches are (in some sense) determined based off (some of) the bits in the instruction register. Characteristics of microcode include: wide instructions (20-40 bits) that perform multiple operations in parallel (e.g. ALU operation and register-register copy) and hardware dispatch to the appropriate microcode to handle each microcoded instruction via zero-overhead multiway branches. I wouldn't call a 6502-like assembly language microcode, even if it implements an interpreter for a user-level instruction set, because it lacks the relevant characteristics of true CPU microcode. [1] https://www.reenigne.org/blog/8086-microcode-disassembled/ https://www.reenigne.org/blog/8086-microcode-disassembled/