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.
I guess the privileged ISA still being a draft prevents full application processors from being rolled out. But is there anything preventing micro-controllers being mass produced? Why isn't there an Arduino with a RISC-V micro-controller yet?
Like another poster answer, there is the lowrisc effort that is probably closest to bringing out a risc-V micro-controller board?
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.
Yes, lowrisc seems to be more like a Raspberry Pi than an Arduino.
But if it's cheap enough, does it matter? You don't have to install a full Linux kernel, you can just run your micro-controller code directly on the metal?
"We did not include special instruction set support for overflow checks on integer arithmetic operations, as many overflow checks can be cheaply implemented using RISC-V branches."
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.
Many overflow checks can be removed with optimization. RISC-V's compressed encoding has shown to be ~70-80% more compact, so it has room for overflow checks. The efficiency of the architecture can always compile it out by time it hits microcode
I pioneered most of WebKit's overflow check optimizations, and our compiler is bleeding-edge when it comes to eliminating them. Still, the overwhelming majority of the checks remain, because most integer values are not friendly to analysis (because they came from some heap location, or they came from some hard math, etc).
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.
Why do you suppose they left it out? Is it merely a matter of "cheap implementation" being purely subjective, and hence they might have thought it as cheap, while you seem to disagree? Or could there be a more pressing reason, but "Oh well, its cheap enough anyway" is more of an excuse?
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.
Here, ASLR is "Address space layout randomization" (https://en.wikipedia.org/wiki/Address_space_layout_randomiza...), a technique to protect from buffer overflows and other such exploits where an attacker makes guesses about where things are in memory part of the attack.
14 comments
[ 4.4 ms ] story [ 43.0 ms ] threadThis 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.
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.
But if it's cheap enough, does it matter? You don't have to install a full Linux kernel, you can just run your micro-controller code directly on the metal?
Thus time to market (as in "I wanna play with this nooow") is improved for the latter approach.
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.
http://joeduffyblog.com/2015/12/19/safe-native-code
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.
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.