If you're doing something embedded nothing prevents you implementing multiply but not divide. RISC-V gcc has an option to use an instruction for multiply but ru

If you're doing something embedded nothing prevents you implementing multiply but not divide. RISC-V gcc has an option to use an instruction for multiply but runtime library call for divide. In fact, even if you claim to implement the M extension (both multiply and divide) all that is necessary is that programs using those opcode work -- but that can be via trap and emulate. If your overall system can run binaries with multiply and divide instructions in them then you can claim M-extension. Whether the performance is adequate is between you and your customers. Note that there are also vast differences in performance between different hardware implementations of multiply and divide, with 32-64 cycle latencies not unheard of. The same applies for implementing a subset of other extensions in hardware. You can implement the uncommon ones in the trap handler if that will meet your customer's performance needs.