Zmmul

Multiply Without Divide

https://github.com/riscv/riscv-isa-manual/blob/master/src/m.tex

(see section "Zmmul Extension, Version 0.1")

Public Review Comments

There was a single comment about the spec that simply questioned the need for it and how it might cause tool fragmentation
(as opposed to specifics of the spec itself)

IMHO, I think it trades off implementation complexity with increasing the fragmentation to extensions,
which increase the burden on IP vender and compiler engineers.
I wonder if it is really worth to add this extension and splitting mini-extensions out from current extension?

Dividers can have different implementations, each with different trade-offs, providing many choices for architects.
Those who even don't want to introduce even a single adder in some small ASIC designs  can still use the GCD algorithm
while sharing ALU as adder. This won't increase the implementation difficulty or area cost (maybe only add a FSM).
For FPGA users, they also can leverage the DSP block inside FPGA
(for example: https://www.xilinx.com/support/documentation/ip_documentation/div_gen/v5_1/pg151-div-gen.pdf)
So I don't think divider provides difficulty or burden to small ASIC core or FPGA implementations.

There was a discussion about trap&emulate for div, but further spec clarification made it clear that isn't allowed.

My answers were 2-fold:
 - We shouldn't need to dictate that FPGA implementations require FPGAs that have DSP blocks
 - Gate cost is not the only cost; design verification for a block that completely changes a simple fixed pipeline to a variable one
   (especially with concurrent interrupt events, returning loads and stores, etc) will add cost to the implementation.

The other answer was that there is a possibility of fragmentation, but that will be filtered by the mandates of profile definitions, e.g.

 RVA profiles (for apps processors) will mandate the M extension, and so software in this space can remain ignorant of Zmmul's existence. 
The RVM profiles might(?) declare that M is supported-optional whereas Zmmul is unsupported-optional,
so standard library vendors shouldn't feel obligated to support Zmmul by itself. 
In effect, this would restrict Zmmul's applicability to those who are willing to support their own software stacks.