False. For example, JavaScript add/sub will require 3x more instructions on RISC-V than x86 or ARM. Same will be true for any other language requires (either implicitly, like JS, or explicitly, like .NET) overflow checking. Good luck with that, lol.
I doubt that the architecture will compile out signed integer addition overflow checks, which are the most common. They are brutal to express correctly without an overflow bit, and the architecture will have a hard time with this.
In general, I wonder, what are the economics of producing micro-controller chips? I assume there is something like a minimum chip complexity (number of transistors), below which it doesn't make the thing cheaper since you need to produce a package big enough to have pins to connect to the outside world? And as feature sizes are reduced, that minimum complexity goes up?
And of course, for something like a hobbyist product like Arduino, the price of the micro-controller chip itself must be a (very) small fraction of the price of the board?
All this being a long-winded way of saying I hope that a hypothetical RISC-V based micro-controller board wouldn't be noticeably more expensive than an equivalent 8-bit AVR micro-controller board? Oh, and compatibility with Arduino shields, and programmable with Rust. And a pony.
It still won't do execute-only and true read-only memory. We've had true read-only for ages now on x86, and just got execute-only. You need these: rw- r-- --x
It still has poor support for ASLR, especially the limited-MMU variants. Even the most limited version should be able to require that the uppermost address bits be something randomish, even if it's only a per-priv-level random cookie.
This is version 2.1 of the document describing the RISC-V user-level architecture. Note the frozen user-level ISA base and extensions IMAFDQ version 2.0 have not changed from the previous version of this document, but some specification holes have been fixed and the documentation has been improved. Some changes have been made to the software conventions.
