Yes but that does seem to be better than not standardizing it as an architecture, but you can always fall back on the trap in the absence of being able to link with binaries from the preferred Zmul only architecture.
You're thinking of cellphones and workstations, but Zmul is about microcontrollers, not workstations. The temperature controller in your Pinecil soldering iron might not implement division or have a trap mechanism at all, nor enough Flash to waste some on unused division trap handlers, and there's no point in trying to link a precompiled copy of OpenSSL into its firmware anyway. Nevertheless, if it's RISC-V, you can compile its firmware with GCC or clang. And hardware multiplication is super useful for real-time control systems with, for example, PID controllers in them.
Of course you don't need an OS and a 32-bit computer in your soldering iron, but they are nice.
An OS is nice because you can have multiple real-time tasks with different priority levels, so that you can, for example, update the screen without worrying that it will screw up the PID control loop maintaining the iron's temperature.
You don't need a screen, but a screen is nice because you can see what temperature the iron is set to and what temperature it's measuring. This makes it easier to set the temperature. Also IronOS lets you set the cutoff voltage so you don't kill your batteries by draining them down to zero, and it has an option to correct inaccurate temperature readings from the tip by calibrating the tip.
PID temperature control is nice, not only because the iron is ready for use much more quickly, consumes much less energy (making battery power practical), and weighs less, but also because it allows you to solder things to big copper pours without overheating your iron all the time, which means you burn components and lift traces a lot less often. This is especially nice if a heat-damaged component might not fail until after the circuit board is on orbit, which makes it impractical to replace, or until it's in use in a life-critical application, which makes replacement the least of your worries. But you don't need it.
A 32-bit processor is nice because it means you can use 32-bit math for everything instead of constantly worrying about overflow. Also, you can address the entire 128 KiB of Flash without shitty memory segmentation headaches when you're writing the firmware. 128 KiB of Flash is nice because it's easy for even a single person to write more than 64 KiB of code, even with RV32C's superior code compactness and without using libraries — though, to be fair, an alternative way to get 128 KiB or 256 KiB of code space is to make your code space word-addressed instead of byte-addressed, and then make your instructions 16 bits or 32 bits long. Generally this requires a Harvard architecture, which is common in microcontrollers but not ideal.
None of these nice things requires or even benefits from a division instruction (though in practice they probably do need interrupt handling and illegal-instruction traps, which could be used to emulate division if it were really necessary). So I always thought it was kind of goofy that the M multiply-instruction extension, crucial to DSP work, was saddled with this white elephant of hardware division support. I'm glad to see that's fixed as far as it can be with Zmmul.
The GD32VF103 used in the Pinecil doesn't have memory protection, so IronOS https://github.com/Ralim/IronOS might not be the kind of operating system you're thinking it is. It doesn't have, for example, a filesystem, a command prompt, a GUI, a task list UI, or a networking stack. I don't even think tasks are created and destroyed at runtime; all the running tasks are compiled into the OS image.
Having an OS and a 32-bit microcontroller in your soldering iron might be a terrible idea: for example, it could include malware that displays advertisements or disables your soldering iron if you haven't paid your monthly subscription. The Pinecil solves this problem by being 100% free software, so that even if the IronOS maintainers try to pull something like that, you have the freedom to fork their code and remove the malware.
You still have the problems that the iron can have more complicated malfunctions and is harder to repair than an iron that is just a resistor that plugs into the wall. But I think the advantages of tighter control more than make up for that.
But if you really need to, you can solder your circuits by heating up a chunk of brass in the flame of your gas stove, then pressing it to the circuit board before it cools off. I've done it. But I'd rather not.
I appreciate the thoughtful reply. Yes, maybe not having to contort yourself to do everything with an 8-bit PIC is a nice upgrade in quality of life. I'm just a grumpy old man and grouse at putting the 32-bit mcu and screen forth as a top reason a soldering iron is good. Agree 100% on PID control, which my WES51 does pretty well and is still a good step above the dumb resistive heat firehoses.
