LWN: Comments on "An introduction to RISC-V"

An introduction to ugly RISC-V assembler

Jonno — Sun, 25 Mar 2018 14:53:03 +0000

> Yes I find the MIPS-inspired asm to be annoying, particularly the fact that there's no common concept of source and destination, eg:

In RISC-V assembler the destination (if any) always come first. However, note that the non-atomic store instructions (sd, sw, sh, and sb) does not have a destination, only two operands (a value and an address) and a side effect (a memory write)...

An introduction to ugly RISC-V assembler

rwmj — Fri, 23 Mar 2018 11:20:44 +0000

Yes I find the MIPS-inspired asm to be annoying, particularly the fact that there's no common concept of source and destination, eg:

li a0, immediate  # dst, src
lw a0, addr   # dst, src
sw a0, addr   # src, dst

I also programmed the 68k and Z80 as a commercial programmer back in the day, but I recognize that few people are hand coding large volumes of asm these days, even for embedded platforms.

In fact with complex rules for immediate loads, pervasive use of pseudo instructions (both lw and sw above aren't "real" instructions, they expand to one or two base instructions), "linker relaxation", compressed instructions, superscalar, macro-op fusion etc I doubt it's really feasible.

An introduction to ugly RISC-V assembler

farnz — Thu, 22 Mar 2018 15:10:44 +0000

RISC-V looks a lot more like MIPS or PowerPC to me than it does to x86 or 68k.

An introduction to ugly RISC-V assembler

deater — Thu, 22 Mar 2018 14:42:38 +0000

> But I guess they wanted to look like ugly and stupid x86

I don't want to get involved in an assembly-language beauty discussion, but if you know anything about the history of RISC-V and the people involved it's pretty clear RISC-V assembly language is more or less exactly the same as MIPS.

The main thing I have against MIPS assembly is that there are two names for each register (the generic one, and then the mnemonic one (such as a0, s0, etc.)) and it can get really confusing trying to remember the mapping between them.

An introduction to ugly RISC-V assembler

kragil — Thu, 22 Mar 2018 13:02:54 +0000

I wish they would have used assember like the Motorola 68xxx. It was so much nicer!
One example:
move.w #$500,d0
moves the word hex 500 to d0. The list would go on and on. It was so much more readable and nicer than x86-assembler.
But I guess they wanted to look like ugly and stupid x86 for some reason (IMNSHO).

An introduction to RISC-V

rwmj — Sat, 17 Mar 2018 14:50:35 +0000

It should read "address of the first byte". It's definitely not possible to determine this from the first byte of an x86 instruction, eg. the LOCK prefix is a counterexample.

An introduction to RISC-V

ianmcc — Sat, 17 Mar 2018 13:53:03 +0000

I am surprised it is possible to determine the length of an x86 instruction after just one byte. What about prefixes?

An introduction to RISC-V

flussence — Thu, 15 Mar 2018 20:08:51 +0000

Oh, it's right there in section 12.7: 16 bit instructions unless the bottom two bits are set, then it's a long instruction. That looks pretty similar to how websockets encodes length, makes sense to me now. Thanks.

An introduction to RISC-V

rwmj — Thu, 15 Mar 2018 07:58:50 +0000

>I'll take “horrible to decode” at face value in any case

The Linux kernel is capable of decoding the length of an x86 instruction, given the first byte. The code is fairly intricate: arch/x86/lib/insn.c

Initial 8086 chips didn't have to worry about instruction boundaries because the microcode fetched, decoded and executed bytes one at a time. Over time x86 encoding has piled complexity on complexity. Now we know that instruction prefetch queues are a thing and that you have to split on instruction boundaries early so it's possible to design something to make this much simpler.

An introduction to RISC-V

roc — Thu, 15 Mar 2018 03:57:04 +0000

https://riscv.org/specifications/ chapter 12.

You can figure out the length of an instruction by decoding the first 16 bits, and 16 bits is the minimum instruction length. (This might change if they ever decide to add instructions more than 24 bytes long.)

The bytes of an instruction after the first 16 bits can be anything, so there is no way, given an arbitrary address, to reliably find the start or end of the instruction, unlike UTF8 where given a pointer you can find the start and end of the character. This seems like an OK tradeoff though.

An introduction to RISC-V

flussence — Thu, 15 Mar 2018 00:05:19 +0000

> Unlike x86, variable length does not have to mean "horribly complex to decode". The encoding ensures that the processor can easily see the length of every instruction in its prefetch queue by decoding a few bits in a uniform location.
Just wondering aloud, as I have no idea where to begin to look this up: does it resemble UTF-8 with a unary length prefix (but without UTF-8's other inefficiencies)? Or is it something different? I'm curious what works best for hardware with no legacy compat to worry about.

(I'll take “horrible to decode” at face value in any case - I can't even make sense of x86's mnemonic names most of the time!)

An introduction to RISC-V

JoelSherrill — Wed, 14 Mar 2018 18:41:48 +0000

Sorry for not pointing that out also. RTEMS uses the FreeBSD TCP/IP stack among other pieces.

An introduction to RISC-V

willy — Wed, 14 Mar 2018 18:31:14 +0000

There's also at least a FreeBSD port to RISC-V:
https://wiki.freebsd.org/riscv

An introduction to RISC-V

JoelSherrill — Wed, 14 Mar 2018 16:58:47 +0000

Thanks for the article. Linux is not the only free OS supporting RISC-V. The free real-time operating system RTEMS (RTEMS.org) also has a port to the 32 and 64-bit RISC-V.