
Updated RISC-V Instruction Set Manual: Version 2.1 - svens_
http://www.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-118.html
======
hga
From the Preface of the linked PDF:

 _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._

------
tropo
Security:

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.

~~~
unwind
Here, ASLR is "Address space layout randomization"
([https://en.wikipedia.org/wiki/Address_space_layout_randomiza...](https://en.wikipedia.org/wiki/Address_space_layout_randomization)),
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.

------
legulere
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?

~~~
jabl
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.

~~~
legulere
But lowrisc wants to be a full processor with MMU and everything able to run
Linux (just without a graphics card)?

~~~
jabl
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?

~~~
unwind
It might "matter" because doing a full application-level chip is more work
than doing a limited microcontroller-level chip.

Thus time to market (as in "I wanna play with this nooow") is improved for the
latter approach.

------
pizlonator
"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.

~~~
__s
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

[http://joeduffyblog.com/2015/12/19/safe-native-
code](http://joeduffyblog.com/2015/12/19/safe-native-code)

~~~
pizlonator
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.

