
RISC-V Stumbling Blocks - lelf
https://x86.lol/generic/2020/01/01/riscv-intro.html
======
thethirdone
I wrote an educational simulator for RISC-V [0] two and a half years ago and
the documentation for RISC-V has gotten marginally better. There a fair number
of universities using RISC-V to teach that have published their slides and
such publicly [1]. However those is not super helpful for people who already
understand assembly and computer architecture reasonably well. The best way I
can see to get up to speed is to read some example demonstrating each
instruction. I have thought about a site that has a table of instructions that
links to an online simulator [2] to let you step through an example detailing
edge cases.

The best source of simple assembly examples I know of would be the tests from
my project [3]. Though those could be a lot more helpful for a human reading
them.

As for simulators, there are quite a few. The website lists a bunch [4]. I am
not sure how many would support any kind of machine mode memory mapping
though.

[0]:
[https://github.com/TheThirdOne/rars](https://github.com/TheThirdOne/rars)

[1]: [https://github.com/riscv/riscv-teach](https://github.com/riscv/riscv-
teach)

[2]: [https://venus.cs61c.org/](https://venus.cs61c.org/)

[3]:
[https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d...](https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d80370c18be5524e95f0db/test)

[4]: [https://riscv.org/software-status/](https://riscv.org/software-status/)

------
jhallenworld
I just tried the Project Trellis open source FPGA tool chain for RISC-V. I was
forced into it: a few years ago I bought the Lattice ECP5-5G Versa Dev kit (on
sale at the time for $99, $200 now I think). The Lattice tools for the FPGA on
this board requires a license. Well the license ran out, and I don't want to
pay $900 for a Diamond license.

Anyway, I got this example from Project Trellis to work on this board. It uses
this "PICO RISC-V" (the entire CPU is in a single Verilog file):

[https://github.com/SymbiFlow/prjtrellis/tree/master/examples...](https://github.com/SymbiFlow/prjtrellis/tree/master/examples/picorv32_versa5g)

I think it would be straightforward to build a Linux capable RISC-V system for
this board using this free tool chain. The board has SDRAM, FTDI UART and SPI-
flash. It does not have an SD slot, but maybe could be wired in with the
expansion headers.

This ULX3S board also looks promissing, but is not available yet:

[https://www.crowdsupply.com/radiona/ulx3s](https://www.crowdsupply.com/radiona/ulx3s)

What's very cool is that low end ECP5 FPGAs are around $5. I think RISC-V on
an ECP5 with LCD touch interface might be the cheapest available option for a
Linux microcontroller with a touch LCD interface. By available, I mean where
you can easily buy the chips on mainstream distributors (otherwise it would
for sure be some AllWinner chip).

~~~
kersny
A RISC-V linux system for the ECP5 can be built with the FOSS toolchain using
vexriscv and litex:

[https://github.com/litex-hub/linux-on-litex-
vexriscv](https://github.com/litex-hub/linux-on-litex-vexriscv)

also, step by step using a different core (rocket):
[https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-
build-a...](https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a-
trustworthy-freelibre-linux-capable-64-bit-risc-v-computer.html)

~~~
jhallenworld
I'm amazed to see the preferred toolchain for LiteX for ECP5 listed as
"Yosys/Trellis/Nextpnr" (and vendor proprietary tools for the other families).

The rocket core mentions 102% of space used of an 85K LUT FPGA and having to
deal with it. I wonder which core is using so much space? I have more
experience with vendor soft cores, and they would use much less..

------
Quequau
This:

> If you want to do any OS work, you need a system that implements the
> Privileged ISA. Supporting the Privileged ISA is synonymous to being able to
> run UNIX-like systems, because it brings user-/supervisor-mode distinction
> and paging. Working on real hardware is generally preferred to working in
> emulators, because the code eventually has to run on metal anyway and
> emulators can be too forgiving for certain classes of problems. There is a
> plethora of RISC-V microcontrollers for a couple of dollars that all don’t
> support the Privileged ISA. At the time of writing, the only board you can
> buy that does support it is the $1000 HiFive Unleased, which was beyond my
> “I just want to play around with this” budget.

Suggests to me that it's at least part of why Stephen Marz [0] isn't trying to
target a specific board with his project (which has been posted here a few
times and I'm sorta following along). That pretty much kills most of the
interest in RISC-V that I had in me.

I guess I'll wait a few more years and check back again later.

[0]:
[https://osblog.stephenmarz.com/index.html](https://osblog.stephenmarz.com/index.html)

~~~
pjc50
For some reason, people have a fantasy that RISC-V is going to give them a
sub-dollar microcontroller that runs Linux, rather than being like ARM where
"microcontroller" and "Linux capable" and "server grade" are three entirely
different market segments.

~~~
Quequau
I've never met anyone who believed that RISC-V was going to give them a sub-
dollar microcontroller that ran Linux before. That seems like a fairly
unreasonable expectation, given today's market and RISC-V's position in it.

~~~
warrenm
I've met folks like that - ones who're getting ready to bet the farm on RISC-V
taking-over not merely IoT, but mobile devices (phones, tablets, watches,
wearables)

------
gumby
TBF Intel's x86 documentation has evolved incrementally over the last 40+
years. And it comes from an older tradition of engineering documentation which
seems to have fallen by the wayside over the last 20 years or so. At an
extreme, some ARM vendors like Mediatek don't even produce data sheets, as
their model is one of chip+consulting.

------
ncmncm
The riscv people missed some serious opportunities for fundamental
improvements, probably the last such opportunity in this generation.

Perhaps the biggest was that the comparison instruction should have had the
condition being looked for in the instruction, and put the result in register
0 as a 0 or ~0 (= -1). Register renaming can then carry it through pipelines.
Subsequent instructions may AND register 0 with other values, or subtract it
from them, avoiding frequently mispredicted branches.

~~~
rwmj
RISC-V is meant to be a simple, unsurprising, boring architecture, with any
clever stuff (such as macro op fusion) being done at the microarchitecture
level. It's not a project for researching new architectures.

~~~
beefhash
I really wish it was just one tiny less bit simple. The RISC-V spec doesn't
specify that multiplication instructions (if implemented) need to be constant-
time. Which means RISC-V cores will need stupid hacks for cryptography like
these: [https://bearssl.org/ctmul.html](https://bearssl.org/ctmul.html)

~~~
0xcde4c3db
A big part of the RISC-V story is the idea that microarchitecture decisions
belong to the implementation and not the ISA specification. Specifying that
multiplication must be constant-time would effectively be specifying that
area-optimized cores aren't allowed to provide the multiplication
instructions.

~~~
anoncake
Couldn't this be solved by having constant-time and regular multiplication
instructions?

~~~
justincormack
Arm 8.4 has a constant time flag that makes most instructions constant time,
without changing the instruction set. You could definitely add this to risc-v.
Or just make a constant time implementation.

------
Annatar
"While reading the rest of this post, please keep in mind: RISC-V is simple!"

That's either a lie, or the author is severely traumatized from coding on x86
and is suffering from the Stockholm syndrome. Poor author; I feel sorry for
the bloke.

Code on UltraSPARC or MC68000 family of processors and then you will know what
simple means. The instruction set of RISC-V is insane, absolutely insane.

~~~
rwmj
The parent comment is complete drivel. RISC-V has a very small instruction set
(under 50 instructions in the base arch) and lacks the weirdness of UltraSPARC
(register windows! branch delay slots!). 680x0 was a joy to program in
assembly, I used to be a commercial 68k developer on VMEbus systems, but those
days are long gone and are never coming back. There is simply no point
optimizing a modern architecture for hand-written assembler coding.

~~~
CalChris
tagged integers

I'm not a RISC-V fan-boi by any stretch of the imagination but I have to admit
that they certainly cleaned up RISC which 40+ years later was in order for a
thorough house cleaning. X86 is gloriously messy but RISC had become quite a
mess as well.

~~~
floatboth
> RISC had become quite a mess as well

That's kind of a nonsensical statement — "RISC" is not a particular ISA, RISC
is a vague methodology/philosophy.

RISC-V is not officially related to any previous ISA, but people like to call
it "MIPS in a trenchcoat". RISC-V got off the ground in academia, and MIPS was
often used for teaching before. They are quite similar in some ways, but it's
really independent.

~~~
CalChris
That is being overly pedantic. I'm actually paraphrasing chapter 2 of Andrew
Waterman's thesis, _The Design Of The RISC-V Instruction Set Architecture_.

[https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...](https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf)

~~~
ncmncm
I wonder why they studiously avoided even ever mentioning IBM Power
architecture. It is considerably more open than MIPS or ARM, and quite a lot
cleaner than either has become.

~~~
CalChris
Well, open-ness wasn't what RISC-V was looking at in ISA models.

Is Power _clean_? Myself, I've never liked its special purpose Condition, Link
and Count registers. I don't see the need for a Branch Processing Unit being
an architectural division. The last time I checked, pushing a register value
across that boundary was slow. It wasn't handled by a renamer.

~~~
ncmncm
Clean- _er_.

Not suggesting it as a substitute for RV, just wondering why they saw nothing
in it to learn from. It's not defunct like PA-RISC, Alpha, and (forgive me)
SPARC, and quite some research has gone into it.

~~~
CalChris
I have to admit that leaving Power out of the analysis is a bit odd; the
Berkeley crew can be rather parochial. I wrote PowerPC assembly back when the
Mac used that ISA and liked it. Alpha lives on, to a degree, in the Sunway
Chinese supercomputers. Intel should have gone with Alpha rather than Itanium.

[https://en.wikipedia.org/wiki/Sunway_(processor)](https://en.wikipedia.org/wiki/Sunway_\(processor\))

Is there an architectural feature in Power you think should have been
considered by RISC-V for inclusion or omission?

My 2030 prediction is that Intel will have a simpler x86 where they discard a
shit ton of legacy.

~~~
ncmncm
Don't know it well enough to suggest any. That is what inclusion in the survey
would have been useful for.

It is conventional to complain about condition codes, but I don't see what
would be debilitating about just appending a set of condition codes to each
register, so that renaming a register carries them along. Going from storing
64 bits to 70 bits each would't break the bank.

~~~
CalChris
That is a really good idea. Sadly, RISC-V is an ultra ultra conservative
design bereft, nay avoiding anything resembling an idea.

I _believe_ that an element of your idea is done in modern x86
microarchitectures. I was having an argument on LLVMdev about a peephole
optimization and partial register update stalls. Eventually one of the Intel
compiler people popped in on the thread and settled the argument, saying:

 _Regarding the partial EFLAGS write, modern OOO processors independently
rename the carry flag, et al, so this is no longer a problem._

