3 ms·

As of early 2016, with the GCC port at that time, RV32GC was as dense as Thumb, and RV64GC was denser than AArch64 and every other major 64-bit ISA, including A

As of early 2016, with the GCC port at that time, RV32GC was as dense as Thumb, and RV64GC was denser than AArch64 and every other major 64-bit ISA, including AMD64. Though RV64G (no C) was in some extreme cases up to 50% larger than AArch64 (due to inlining memcpy and memset, which are a bit larger without compressed instructions), but usually around the same (except MIPS64, which is way larger than the other 64-bit ISAs, probably because of exposed delay slots). [0] There's some indication that density should have increased somewhat since then, but I haven't looked at it myself. [0]: https://youtu.be/Ii_pEXKKYUg https://youtu.be/Ii_pEXKKYUg

Symmetry 8y ago
That's why I have a lot more faith in RISC-V's ability to take on relatively high end embedded tasks than lower end ones. I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such and program memory is at a premium in those places.
- TomVDB 8y ago
  The cost of compression is very small for low performance designs (single instruction in-order issue). It's very straightforward to implement. It gets harder for more complex designs though. But for cases where you want to replace a Cortex M2, the area increase will be trivial.
- duskwuff 8y ago
  Cortex-M2? ¿Que? CM2 doesn't exist -- the naming scheme jumps straight from CM1 (which is FPGA-only) to CM3.
- audunw 8y ago
  > I'd expect compression to be too expensive It's not the kind of compression you might be thinking of. It's just 16-bit "shortcuts" for some of the common 32-bit instructions. The impact in gate count should be minimal. In a lot of these applications you'll have the code in on-chip non-volatile memory which means reducing code size may also reduce chip area. I think with relatively little increase in gate count you could also make some sequences of two 16-bit instructions execute simultaneously, which could yield nice performance improvements for micro-controller cores. Also, you might be surprised at how "big" many micro-controllers are becoming these days.
- microcolonel 8y ago
  > I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such... Decoding the "compressed" instructions is actually pretty straightforward, it doesn't add much complexity to a design. ARM Cortex M0+/M3/M4 implements a similar (but more complex) "compressed" instruction set called Thumb, and comparable RISC-V cores available from SiFive are smaller, faster, and more efficient. In a very small RISC-V core by the venerable Clifford Wolf called PicoRV32 [0], you can look at the complexity introduced by configuring it with the COMPRESSED_ISA option. > ...and program memory is at a premium in those places. Program memory is one thing, but on processors of all sizes, code size has a big impact on performance in common types of program. [0]: https://github.com/cliffordwolf/picorv32 https://github.com/cliffordwolf/picorv32

Symmetry 8y ago

That's why I have a lot more faith in RISC-V's ability to take on relatively high end embedded tasks than lower end ones. I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such and program memory is at a premium in those places.

TomVDB 8y ago
The cost of compression is very small for low performance designs (single instruction in-order issue). It's very straightforward to implement. It gets harder for more complex designs though. But for cases where you want to replace a Cortex M2, the area increase will be trivial.
duskwuff 8y ago
Cortex-M2? ¿Que? CM2 doesn't exist -- the naming scheme jumps straight from CM1 (which is FPGA-only) to CM3.
audunw 8y ago
> I'd expect compression to be too expensive It's not the kind of compression you might be thinking of. It's just 16-bit "shortcuts" for some of the common 32-bit instructions. The impact in gate count should be minimal. In a lot of these applications you'll have the code in on-chip non-volatile memory which means reducing code size may also reduce chip area. I think with relatively little increase in gate count you could also make some sequences of two 16-bit instructions execute simultaneously, which could yield nice performance improvements for micro-controller cores. Also, you might be surprised at how "big" many micro-controllers are becoming these days.
microcolonel 8y ago
> I'd expect compression to be too expensive, transistor wise, for many roles where you'd use an ARM Cortex M2 or such... Decoding the "compressed" instructions is actually pretty straightforward, it doesn't add much complexity to a design. ARM Cortex M0+/M3/M4 implements a similar (but more complex) "compressed" instruction set called Thumb, and comparable RISC-V cores available from SiFive are smaller, faster, and more efficient. In a very small RISC-V core by the venerable Clifford Wolf called PicoRV32 [0], you can look at the complexity introduced by configuring it with the COMPRESSED_ISA option. > ...and program memory is at a premium in those places. Program memory is one thing, but on processors of all sizes, code size has a big impact on performance in common types of program. [0]: https://github.com/cliffordwolf/picorv32 https://github.com/cliffordwolf/picorv32