RISC-V's integer multiplication extension doesn't do the lo/hi trick MIPS did, and it doesn't specify a latency; that is, the integer multiplication opcode, if your chip has one, returns its value in a normal register, not split into a special lo register for the low bits and hi for the high bits, and it executes in a normal sequence with the others from a software perspective, as opposed to MIPS, where it was specified to execute sychronously with the normal instruction stream, and you'd only stall the pipeline if you tried to read lo or hi too early after the mutiplication opcode had issued, before the actual arithmetic was completed.

https://stackoverflow.com/questions/27893526/mips-are-some-a...

> Programming Notes:

> In some processors the integer multiply operation may proceed asynchronously and allow other CPU instructions to execute before it is complete. An attempt to read LO or HI before the results are written interlocks until the results are ready. Asynchronous execution does not affect the program result, but offers an opportunity for performance improvement by scheduling the multiply so that other instructions can execute in parallel. Programs that require overflow detection must check for it explicitly.

> Where the size of the operands are known, software should place the shorter operand in GPR rt. This may reduce the latency of the instruction on those processors which implement data-dependent instruction latencies.

(MIPS32TM Architecture For Programmers Volume II: The MIPS32TM Instruction Set, mul / mult instrutions)

It's... a bit more low-level than assembly ISAs are typically designed to be these days.