RISC-V

[paulunderwood]

I ordered another Longan Nano, this time making sure it came with the screen and case! I spent many hours trying to get something to work -- so I can run my aribitrary arithmetic development programs. I found this excellent page that has a download which when unzipped in the right place ran the screen in all its techocolour. I was then on a position to start hacking. This is not by running a debugger but making a changes and testing for the expected results on the screen. Oh what fun!

[Xyzzy]

https://arstechnica.com/gadgets/2021...ased-linux-pc/

[paulunderwood]

Originally Posted by Xyzzy

https://arstechnica.com/gadgets/2021...ased-linux-pc/

Can you tell me whether the BeagleV will be 32 bit or 64 bit?

Edit; according to https://www.tomshardware.com/news/be...iscv-announced it had a dual core 64 bit U74 CPU.

[ewmayer]

GMP's Torbjörn Granlund weighs in on RISC-V, and does not mince words:

Date: Mon, 20 Sep 2021 11:53:13 +0200
From: Torbjörn Granlund <tg@gmplib.org>
To: gmp-devel@gmplib.org
Subject: Risc V greatly underperforms
Message-ID: <86bl4nefp2.fsf@shell.gmplib.org>
Content-Type: text/plain; charset=utf-8

It seems safe to assume that most people on this list have heard of
Risc V by now, the license-free instruction set.

I trust that much fewer have looked at the technical details. I have,
though, as we implement critical inner loops for GMP in assembly.

My conclusion is that Risc V is a terrible architecture. It has a
uniquely weak instruction set. Any task will require more Risc V
instructions that any contemporary instruction set. Sure, it is
"clean" but just to make it clean, there was no reason to be naive.

I believe that an average computer science student could come up with
a better instruction set that Risc V in a single term project. It is,
more-or-less a watered down version of the 30 year old Alpha ISA after
all. (Alpha made sense at its time, with the transistor budget
available at the time.)

Let's look at some examples of how Risc V underperforms. First,
addition of a double-word integer with carry-out:

	add	t0, a4, a6	// add low words
	sltu	t6, t0, a4	// compute carry-out from low add
	add	t1, a5, a7	// add hi words
	sltu	t2, t1, a5	// compute carry-out from high add
	add	t4, t1, t6	// add carry to low result
	sltu	t3, t4, t1	// compute carry out from the carry add
	add	t6, t2, t3	// combine carries

Same for 64-bit arm:

	adds	x12, x6, x10
	adcs	x13, x7, x11

Same for 64-bit x86:

	add	%r8, %rax
	adc	%r9, %rdx

(Some additional move insn might be needed for x86 due to the
2-operand nature of this arch.)

If we generalise this to GMP's arbitrarily wide addition, we will end
of with 2 to 3 times more instructions, and go from just over 1 cycle
per 64-bit result word to 3 cycles per word. The 3 cycles will happen
even for a wide implementation which could execute a large number of
instructions in parallel. The critical path will be add->sltu->add
which are three dependent instructions i.e. 3 cycles.

I have heard that Risc V proponents say that these problems are known
and could be fixed by having the hardware fuse dependent instructions.
Perhaps that could lessen the instruction set shortcomings, but will
it fix the 3x worse performance for cases like the one outlined here?
Why not provide a decent instruction set instead?

I don't think designing a decent ISA is terribly difficult. Designing
a great ISA is. Designing something like that Risc V is trivial.

Full disclosure: I have no financial or other interest in any computer
architecture mentioned here or not mentioned here. I really like the
idea of a license-free ISA.

--
Torbjörn
Please encrypt, key id 0xC8601622

[retina]

Originally Posted by ewmayer

GMP's Torbjörn Granlund weighs in on RISC-V, and does not mince words:

Performance is just one dimension to consider for any CPU.

Consider the PIC16 instruction set. Performance-wise it is terrible. But the CPUs implementing it sell in large numbers. Clearly not many people buying those care much about the performance. Or if they do then they are in for a nasty shock.

If my FPGA is small then perhaps RISC-V will be a perfect choice for a small low power controller device.

[M344587487]

Does the relatively high number of registers (32 integer and 32 float registers is high right?) have a positive impact to compute-heavy operations?

Originally Posted by ewmayer

GMP's Torbjörn Granlund weighs in on RISC-V, and does not mince words:

I don't doubt they know what they're talking about, but having instructions for low and high words seems strange. If I'm interpreting it right they're saying that 64 bit addition on a 64bit Risc-V chip (that uses RV64I) does the operations with 32 bit integers?

[paulunderwood]

Originally Posted by M344587487

Does the relatively high number of registers (32 integer and 32 float registers is high right?) have a positive impact to compute-heavy operations?

I don't doubt they know what they're talking about, but having instructions for low and high words seems strange. If I'm interpreting it right they're saying that 64 bit addition on a 64bit Risc-V chip (that uses RV64I) does the operations with 32 bit integers?

Not all the registers are general purpose -- some seem to be for I/O.

I like the small set of registers and instructions. They are easy to remember and therefore to program. Oh what fun! Takes me back to the days when I did assembly for the Zilog Z80

RISC-V comes in many flavours -- 32/64 bit, single/multi core, with or without multiplication etc -- It is an open ISA leaving it to hardware implementors to choose what they include.

[axn]

Originally Posted by M344587487

but having instructions for low and high words seems strange.

First, addition of a double-word integer with carry-out:

He's just giving the example of the simplest case of a multi-word addition, i.e. two words. As can be seen from equivalent ARM & x64, this is the addition of two 2x64 integers.

[M344587487]

Originally Posted by axn

He's just giving the example of the simplest case of a multi-word addition, i.e. two words. As can be seen from equivalent ARM & x64, this is the addition of two 2x64 integers.

Thanks it makes sense now, what threw me is that the 64 bit base is defined in the riscv manual relative to the 32 bit base but there's no explicit redefinition of a word now being 64 bit (which should have been obvious), so I interpreted the example completely wrong. So the problem boils down to risc-v not having a carry bit which means there is no add-taking-into-account-previous-carry op, that is an issue.

[chris2be8]

I've met this issue programming in assembly language on a s/370-XA. But that design dates from the 1960s which is a partial explanation (it doesn't even have a stack!) There's no excuse for any IS designed after 1980 not to have a carry bit (unless a very cut down system where low power/cost override everything else).

Even a 8080 or a 6502 had a carry bit.

[paulunderwood]

FWIW (not much) I implemented a base 3 Fermat PRP multi-limb test on my 32 bit Longan Nano. With a 16 bit model, a mult fits in in 32 bits with room for two 16 bit additions without overflow. I do sympathize with the GMP developers about the lack of instructions, but this is RISC and it is open and fun!