seems good, approved

Approved.

.

Approved. Thanks!

My assumption is that the two instructions won't be in the critical dependency chain, so they can be placed anywhere and executed "for free" in more advanced microarchitectures. IDK how much I should worry about this with diversity of RISC-V hardware. And I guess if they are before the branch, there's no need to wait for the branch condition to be ready to retire them.

To save in case of an in-order single-issue CPU? I'm not sure how many of those there are with vector extension support.

Approved

"And also it's a great chance for warriors to start learning V while seeing its usage with some explanation."
Good point, I agree.

I'm not sure that I understand what you mean. The "V" in "RISC-V" stands for 5, not "Vector", the vector extension is entirely optional and most RISC-V CPUs don't implement it.

Sure, you can follow the tradition. I was just copying what most other RISC-V kata are doing, which is void return type and (src, dst) argument order.

The main change was the reference solution. Your solution uses the vector extension, which is not how most people will solve this. Also not many people will understand how your solution works, despite the descriptive comments.

A typo.... obviously

...aaaaand what exactly is cosnt?

Approved, with a follow-up fork for unification with C and NASM translations.

Approved by someone

Approved.